In this guide 6 sections
List every environment, name an owner for each, agree working hours, then schedule the stop and start with the cloud provider’s own scheduler. Databases and queues are special. Announce the first shutdown a week ahead, begin with one low-risk environment, and give every developer an easy override tag for release nights and client demos.
Start with a full inventory of environments
Open the billing console and group spend by account, project and tag, and you will find environments nobody mentioned in any planning meeting. Expect surprises. A staging copy built for a client demo two quarters ago is a typical find, and so is a load-test cluster that was never torn down.
Write each one into a sheet. One row per environment. Record the name, account, instance types, attached volumes and managed services behind it, then mark which ones a person touches daily and which sit idle for weeks. Check the deploy history in your CI tool for the last push to each, because a branch preview that nobody has opened since spring is the easiest first candidate.
- Environment name and the cloud account it lives in
- Compute: virtual machines, container nodes, scaling groups
- Managed databases, caches and message queues
- Load balancers, NAT gateways and static IP addresses
- Last login or last deploy date
Give every environment an owner and a set of hours
An environment without a named owner will never be switched off, because nobody feels allowed to touch it, so assign one person to each. In an agency that person is often the project lead, while in a product team it is usually the squad’s tech lead.
Agree the hours with each owner. A team in one city can run from early morning to evening on weekdays, while a team spread across time zones needs a wider window or a per-person override. Write the rule down. Keep it short. A schedule that fits on one line of a wiki page gets followed, but a schedule with nine exceptions gets ignored by everyone who has to remember them.
- Weekday window, such as start before the first stand-up and stop after the last merge
- Weekend default of off, with a one-click wake-up
- Holiday calendar for shutdown days
- Exceptions for release nights and client demos
Schedule the stop and start, and mind the awkward parts
Use the provider’s own scheduler where you can: instance schedules, scaling group actions, or a small function triggered by a cron rule. Stopping a virtual machine is easy. Scaling a Kubernetes node pool to zero is just as simple, provided the pods have somewhere to land when they return and the persistent volumes stay in their zone.
Databases need more thought. Some managed engines can be stopped for only a limited number of days before the provider restarts them, and others cannot be stopped at all. The answer there is a smaller instance class overnight, or a snapshot taken at night and restored each morning before the first stand-up of the working day. Start order matters too. Database first, cache second, app last.
Check what keeps billing while a machine is stopped, because attached disks, snapshots and reserved addresses still appear on the invoice every month. Compute is only the first saving. Disks come next.
Protect the work that must not stop
Search for night jobs first. Nightly seed-data refreshes, end-to-end test suites and report builds often live in the test environment, and if the schedule kills them mid-run the team loses trust in the exercise.
Add a tag such as keep-alive-until that holds a timestamp, then have the scheduler read it, leave that environment running and log every skip. Developers set it from a chat command or a short script in ten seconds, which removes the main objection to the whole scheme.
- CI pipelines that deploy to the environment at night
- Data migrations and long-running imports
- Demo environments with a booked client call
- On-call rehearsals and load tests
Tell the team, then roll out in stages
Send a short note a week before the first shutdown that says which environments, which hours, how to wake one up and who to ask for help. Repeat it the day before.
Begin with one quiet development environment. Watch the first week closely, counting wake-up requests and any failed morning starts before you add staging and then the remaining test copies. Review the schedule after a month with the owners and tighten the hours where nobody has used the environment out of hours. Share the instance-hours before and after, so the team sees what their patience bought and the finance lead can see the effect on the invoice.
Environment shutdown rollout sheet
A print-ready sheet. Each environment gets a row with columns for name, account, owner, attached services, weekday start and stop times, weekend rule, database handling, override tag, announcement date and first-run result. A second block lists the start order for each stack, from database to cache to application, so the morning wake-up never starts an app before its data.
Open a blank worksheet to printQuestions owners ask
Will switching off environments break developers’ work?
Not if the hours match how people work and a wake-up command exists, because most complaints come from jobs killed mid-run or an environment that fails to start. Test the start order first. Ask each owner to report failed mornings in one shared thread during the first fortnight, so patterns show up before they erode trust.
Can every database be stopped overnight?
No. Some managed engines allow a stop for a limited time only, and some do not allow it at all, so check your engine’s documentation first. Then choose between stopping it, shrinking the instance or restoring from a snapshot each morning, whichever your engine and your morning start time allow.
What still costs money while an environment is off?
Disks, snapshots, static IP addresses, load balancers, NAT gateways and some managed services keep billing while the compute sits stopped overnight or across the weekend. Compute is the largest piece for most teams, yet each leftover item belongs in your inventory sheet so that nothing surprises the finance lead at month end.
Should production ever follow the same schedule?
Almost never. Production serves customers and runs background queues around the clock, so keep the scheduler out by using a separate account or a tag rule that it refuses to touch.