Ask most engineering teams how many hours a week their staging environment actually gets used, and the honest answer is somewhere around 40-50 — a standard work week. Ask how many hours a week it's actually running and billing, and the answer is 168. That gap is pure waste, and it's one of the few cost problems that's genuinely just an on/off switch away from being fixed.

Step 1: Inventory what's actually non-production.

Before scheduling anything, get a real list. This sounds obvious, but "non-prod" sprawls faster than most teams track — dev, staging, QA, a demo environment someone spun up for a sales call eight months ago, a load-testing cluster that gets used twice a quarter. Pull this from tags if your tagging discipline is solid; if it isn't, this exercise usually surfaces the tagging gap too, which is worth fixing at the same time.

Step 2: Match the schedule to the actual usage pattern, not a generic 9-to-5.

Dev and QA environments used by an in-office or single-timezone team → shut down nights and weekends. That alone is roughly 128 of 168 hours down to about 45 — a 70%+ reduction in runtime for that environment, without touching a single instance size or reservation.

Environments used across multiple timezones or by an on-call rotation → don't blanket-schedule these. A blunt nights-and-weekends shutdown on something a distributed team actually touches at 2am somebody's local time creates more friction than it saves in dollars. Profile actual access logs before scheduling anything customer- or team-facing across timezones.

Demo and rarely-used environments → these are usually the biggest single win and the easiest to miss, because nobody "owns" the decision to schedule or kill them. If it's used twice a quarter, it shouldn't be running the other 4,380 hours in between.

Step 3: Automate the shutdown — don't rely on someone remembering.

Manual shutdown discipline fails within about two weeks, every time, for the same reason: someone gets pulled into a deadline, skips shutting things down "just this once," and the exception becomes the norm. Use your cloud provider's native scheduling (AWS Instance Scheduler, a scheduled Lambda + EventBridge rule, or the equivalent in Azure/GCP) so the shutdown happens whether or not anyone remembers it happened. The one-time setup cost is small compared to the compounding cost of it silently not working.

Step 4: Give people an easy override, or they'll route around the schedule entirely.

The fastest way to kill a scheduling policy is to make it painful when someone genuinely needs the environment up outside its normal window. Build in a simple manual override — a Slack command, a button, a documented one-line CLI call — so the answer to "I need staging up at 11pm tonight" is a 10-second action, not a ticket. Teams that skip this step often find engineers spinning up parallel, unscheduled environments to route around the friction, which quietly reintroduces the exact cost you were trying to eliminate.

The actual takeaway: the scheduling mechanism itself is trivial — it's a cron job. The real work is Step 1 (knowing what you actually have) and Step 4 (making the schedule easy enough to live with that people don't quietly bypass it). Teams that skip straight to "just schedule everything 6pm-8am" without those two pieces usually see the savings evaporate within a quarter.

Running a non-prod environment you're not sure is worth keeping scheduled — or worth keeping at all? Reply to this email and I'll help you think through it.