Dev/Staging Server Schedule Template Generator

Dev and staging environments are often the largest single source of preventable AWS waste. They run around the clock, but engineers typically use them for eight to ten hours a day, five days a week. The schedule generator above creates a deployment-ready schedule based on your team's working hours and time zone, in whichever format you need.

Why Schedule Dev and Staging Environments

Non-production environments are ideal candidates for instance scheduling because their usage pattern is highly predictable. Developers work defined hours in defined time zones. Staging environments are used for pre-release testing that follows sprint or deployment cycles. Neither environment needs to be running at 3am on a Sunday.

The economics are straightforward. A standard schedule — on at 7am, off at 8pm, Monday to Friday — results in instances running for roughly 65 hours per week out of 168. That's about 39% of the time, meaning you're eliminating around 61% of the hours you'd otherwise be billed for. For a mid-sized dev environment costing $500/month always-on, that schedule brings the cost down to around $195.

Building the Right Schedule for Your Team

The right schedule depends on three things: your team's working hours, your time zone (or the spread of time zones if you have a distributed team), and whether any automated processes — CI/CD pipelines, nightly test runs — run outside normal hours.

For single-timezone teams, a simple start/stop schedule tied to local working hours is usually sufficient. Build in a 30-minute buffer on each end — start 30 minutes before the team begins work, stop 30 minutes after the expected end of day — to avoid situations where an early starter finds instances still coming online.

If your team has nightly automated test runs or CI/CD pipelines that run against staging, factor those into your schedule window. You don't want the automation to fail because the environment is stopped. Many teams solve this with a short overnight window — for example, allowing staging to run from 1am to 4am for the test suite — and stopping it again until morning. The drag-and-drop scheduling interface in ServerScheduler makes configuring these multi-window schedules straightforward.

Schedule Export Formats Explained

The generator exports schedules in four formats. JSON is a general-purpose representation suitable for storing in version control or feeding into custom automation. Cron format is used by Unix-based task schedulers and EventBridge rules — the generator produces two expressions per environment, one for the start time and one for the stop time.

Terraform format generates a pair of aws_cloudwatch_event_rule resources per environment that you can drop into an existing module. AWS Instance Scheduler format produces the DynamoDB item structure used by the AWS Solutions Library scheduler. If you're planning to move to a managed solution, the comparison tool helps you evaluate options before committing to an implementation approach.

Implementing Schedules With Instance Tags

Regardless of which scheduling tool you use, tagging instances is the most scalable way to manage schedules. Rather than listing individual instance IDs in your scheduling configuration, you tag each instance with its environment — Environment: dev, Environment: staging — and the scheduler applies the appropriate schedule to everything with that tag.

This approach scales naturally as your team adds new instances. A new dev instance tagged correctly is automatically included in the existing schedule without any configuration change. It also makes it easy to review what's scheduled at a glance and to audit your infrastructure governance, a topic covered in more depth in the infrastructure governance guide.

Automating Schedules With ServerScheduler

If you want to skip the manual implementation and go straight to a working schedule, ServerScheduler connects to your AWS account and applies schedules through a visual interface. You define your environments, set the hours, and the platform handles the start and stop events — no Lambda functions, no EventBridge rule management, no cron expressions to maintain.

Schedules can be applied to individual instances or to tagged groups. Changes to a schedule take effect immediately. If a developer needs an environment to stay up outside normal hours — for a late deployment, for example — they can override the schedule for a defined window without changing the recurring configuration. The EC2 scheduled start/stop documentation explains how the feature works in practice.