The arithmetic is easy: a QA environment that runs 24/7 but is only used from 9 to 7, Monday to Friday, is powered on three times longer than it needs to be. Shutting it down outside those hours can cut the non-prod bill in half or better. So somebody writes a cron that stops it at 8pm and starts it at 8am. It works. And that is where the real problem begins.
The cron that worked too well
The first cron goes well, so a second one shows up for another environment, on another machine. Then a third that somebody put on their own VM because it was faster than requesting access to the shared server. Six months later you have half a dozen scripts scattered around, each with its schedule hardcoded, none documented, and the knowledge of "what shuts down what" living in the head of the person who wrote it — who may not be on the team anymore.
- Nobody has a list of which environments have a window and which do not.
- When an environment "woke up switched off" on a day it was needed, there is no fast way to find out which script touched it.
- Changing a schedule means finding the right script, on the right machine, and editing it by hand without breaking cron syntax.
- There is no record of who changed what or when:
crontab -eleaves no history.
The hidden cost is not the money, it is the opacity
The saving from shutting down non-prod is real and worth having. But scattered cron charges you for it another way: in debugging hours every time something "was not there when I needed it", in fear of touching the scripts in case you break something, and in the impossibility of answering simple questions like "why was this environment down on Tuesday at 3pm?". You traded a measurable cost (the invoice) for an invisible one (the team's time and its trust in the system).
One cron that shuts an environment down is automation. Six crons with no inventory and no history are operational debt dressed up as savings.
What changes with governance and an audit log
The alternative is not to stop shutting down non-prod — it is to centralise the decision and leave a trail. A governed operating window has three properties scattered cron never gives you:
- A single inventory: one view of which environments have a window, on what schedule, in which cloud.
- An audit log: every shutdown, start-up and schedule change recorded with who and when. When something wakes up switched off, the answer is one line in the log, not an archaeological dig across six machines.
- Risk-free change: adjusting a schedule means editing one value in one place, not editing crontab on a production box by hand.
The difference shows up the day something fails
With scattered crons, the day an environment is not there when it was needed starts an incident: somebody has to guess which script shut it down, find it, and revert by hand. With a governed window and its audit log, that same event is a ten-second query: who, when, why. The automation does not go away — it gains a memory.
See and govern the windows from one place
Control Cloud treats operating windows as part of the control plane, not as loose scripts: you define each environment's schedule from a single place, across any of your clouds, and every action lands in the audit log. The saving from shutting down non-prod is still there; what you remove is the opacity.
If today you have scattered crons nobody dares touch, the first step is simply to see all your environments together and know which ones are wasting hours. From there, governing the window is the easy part.
Top comments (0)