Resource Scheduling: Start and Stop on Your Working Hours
A dev environment used 55 hours a week does not need to run 168. Scheduling is how you stop paying for the difference.
The arithmetic
A weekday schedule from 08:00 to 19:00 keeps a resource running 11 hours a day, five days a week: 55 of the 168 hours in a week. Over an average 730-hour month that is about 239 running hours instead of 730. ZopNight reports the result the same way: savings are the resource’s 24/7 cost minus what it actually cost under its schedule.
Building a schedule
- Timezone first. Schedules use IANA timezones, so a “stop at 7 PM” fires at 7 PM in Berlin or Bengaluru, not in UTC.
- Cron, with a translation. Start and stop times are cron expressions, and each one is shown in plain words (“every weekday at 8 AM”) before you save. A schedule can hold several.
- A weekly grid. The schedule is drawn on a seven-day, 24-hour grid so gaps and overlaps are visible, and estimated active and inactive hours are shown before you commit.
- Attach resources or groups. Attach single resources, or a resource group so every member follows the same cadence. A resource belongs to one group, so it has exactly one scheduling source.
Order and exceptions
Inside a group ZopNight starts in tiers (storage first, then databases, then compute, then applications) and stops in reverse, with a delay per resource and a tier you can change per resource. The ordering is time-based spacing; it does not wait for one resource to be healthy before starting the next.
When someone needs a box on a Saturday, an override forces a resource or group on or off for a set window, carries a reason, acts as soon as it is set, and expires on its own at the end time you choose. Only one override can be active per target.
What can be scheduled
The supported list covers EC2, RDS and Aurora clusters, Redshift, Neptune, DocumentDB, Lightsail, WorkSpaces, EKS, ECS clusters and services, Auto Scaling groups, Lambda (by concurrency throttling), SageMaker notebooks and HyperPod clusters, App Runner, Elastic Beanstalk, EMR Serverless, Compute Engine, GKE, Cloud SQL, Cloud Run, Memorystore, Vertex AI Workbench, Azure VMs and VM Scale Sets, AKS, Function Apps, Container Apps, serverless Azure SQL Database, Azure MySQL and PostgreSQL Flexible Server, Synapse SQL pools, Data Explorer, SQL Server VMs, SSIS integration runtimes, Azure ML compute, Databricks clusters, pools and SQL warehouses, Snowflake warehouses, and Kubernetes namespaces on all three clouds. Each provider’s own stop semantics apply: an Azure VM is deallocated, an EKS node pool is scaled.
Executing a schedule needs a read + write cloud account. On a read-only account you can build and attach schedules, but nothing is started or stopped.
Where schedules come from
ZopNight also proposes schedules. A schedule recommendation needs roughly three weeks of recent, continuous metrics, and is priced from the running hours it would remove. When it cannot claim a saving honestly, it stays as an advisory with the proposed window. Its Remediate button opens schedule creation with the resource prefilled.
Scheduling notes per service: EC2, Compute Engine, Azure VMs. Background: cron scheduling and resource groups.
Questions we get a lot.
Does a group schedule wait for the database before starting the app?
No. Group ordering spaces actions by tier and delay but does not wait for a resource to report healthy before the next one starts. Set delays that cover your start-up times.
What if someone needs a resource outside the schedule?
Set an override with a reason and an expiry. It forces the resource on or off for that window and clears itself.