Your dev environment doesn't need to run at 3am

Every AWS account has environments that run around the clock — dev, staging, test - but often nobody is using them outside of work hours and the meter is running regardless.

Most teams know this and do nothing about it — it becomes background noise on the bill. This post is about fixing that, permanently, in under 5 minutes.

The quiet cost of always-on infrastructure

Non-prod environments are typically active ~40 hours a week — but billed for 168. This represents roughly 75% of compute spend on idle time, per environment - a whole lot of cheddar. Multiply this across EC2 instances, RDS databases, ECS services — it compounds quickly. NAT Gateways are a hidden offender — data processing charges don't pause when your instances do.

The "fix" most teams reach for: manual stop/start, one-off Lambda scripts, cron jobs that nobody owns. These solutions drift, break silently, and have no visibility. There's no audit trail, no schedule policy, no way to know what's supposed to be running and when.

Introducing Uptime Scheduler

Uptime Scheduler is a scheduling layer for AWS resources — stop and start them on a schedule that matches your working hours, not your billing cycle.

It works by tagging your resources — EC2, RDS, ECS, NAT Gateways — with a schedule. The scheduling engine runs entirely inside your own AWS account via a CloudFormation stack we provide.

Nothing leaves your account — no credentials, no resource data, no IAM access handed to a third party.

The Dashboard is where Uptime Scheduler becomes a product rather than a script

• Visualise all scheduled resources across regions

• Publish stop/start commands and confirm schedules are firing correctly

• Visualise savings analysis

• Multi-account and multi-region support

Deploy once, tag your resources - done

Step 1: deploy the CloudFormation stack into your AWS account — takes under 5 minutes.

Step 2: tag the resources you want to schedule — e.g. uptime:schedule = 9-6 weekdays .

Step 3: EventBridge fires on schedule, Lambda reads the tags, resources stop and start accordingly.

That's it — no agents, no sidecars, no ongoing configuration.

Connect the Dashboard to get full visibility: what's scheduled, what ran, what saved.The Dashboard reads from your stack — it never executes actions directly in your account (optional stop/start commands based on uptime:env tags).

Your infrastructure, your account, your control — the Dashboard is the window, not the key.

Why is it built this way

Platform and security teams are rightly suspicious of SaaS tools that ask for AWS access. Uptime Scheduler doesn't — the CloudFormation stack is handed to you freely, runs in your account, and is yours to inspect

There is no Uptime Scheduler agent polling your account, no credentials stored on our side.

The stack is the engine; the Dashboard is the interface — separating them was a deliberate design decision, not a limitation.

Teams with strict security postures can run the stack standalone with no Dashboard connection at all.

Getting started

Head over to uptimescheduler.com to find out more, start a free trial and see if it's for you or your team.

Tag a few non-prod resources and watch them stop tonight.

First month's saving usually covers the cost many times over.

Personal note: if you try it, I'd love to hear what it saves you — this was built to solve a real problem and real feedback shapes what gets built next.