The 3am pager and the price of a resize

3:04am. The pager goes off. CPU is pinned flat, the queue is backing up, and the fix is obvious and boring: the box is too small. Give it more cores.

You don’t. You restart the workers, shed some traffic, watch it limp along, and open a ticket to revisit sizing next sprint.

Not because you are lazy at 3am. Because some part of you knows that resizing costs more than it should, and at 3am that part of you is doing the arithmetic.

Scaling up is a financial decision. That is the bug.

Look at what a resize actually commits you to under conventional cloud pricing.

Hourly granularity. You need forty minutes of a bigger machine. You buy an hour. Maybe two, because the boundary lands badly.

The ratchet. You scale up during the incident, and nobody ever scales back down. The box stays big for the next fourteen months. This is not incompetence: scaling down means someone has to be confident it is safe, in daylight, with their name on the change. Nobody volunteers for that. Scaling up is an emergency; scaling down is a risk with no upside.

The commitment. If the instance sits under a reserved plan or a savings agreement, you are now paying for the capacity you committed to and the on-demand instance you resized into. You are billed twice for the same fix. Your prudent cost optimisation from last quarter is now actively charging you a fee for responding to an outage.

So the engineer at 3am runs the numbers, badly, on four hours of sleep, and concludes that eating the downtime is cheaper.

And here is the genuinely horrifying part: they are usually right.

Downtime is a cost. It just isn’t on the invoice.

The invoice will faithfully record the extra $4 you spent on cores. It will not record the forty minutes of failed checkouts, the error budget you just set on fire, the customers who tried once and didn’t come back, or the fact that your on-call engineer is now useless for the whole of Tuesday.

Those costs are absolutely real. They are simply paid in a currency your finance team cannot see on a statement — which is why, at 3am, the invisible cost always wins the argument against the visible one.

Pricing did that. Not the engineer.

What we do instead

Per-second billing, and no commitments to unwind. A resize costs what it is actually worth: the seconds you use it for.

Scale up at 3am. Scale back down at 9am, when you are awake, caffeinated, and can read the graph properly. You pay for six hours of a bigger machine, and that is the entire consequence. There is no hourly rounding to buy your way past, no reserved plan to reconcile, and no second bill for capacity you already promised to buy — because you never promised to buy any.

A stopped VM stops billing compute. Turn a machine off and the cores and the memory stop costing you the moment it stops, not at the top of the next hour.

And the caveat, because we would rather you heard it from us than found it on a statement: storage keeps billing while the disk exists. Stopping the VM does not make its volume free. Those bytes are still sitting on our disks, still reserved for you, still costing us something to keep. Compute stops. Storage does not. If you want the storage to stop, you have to delete the volume — and you should not do that until you have a backup, which, as we have written elsewhere, is not the same thing as a snapshot.

None of this is a clever pricing innovation. It is just the absence of the machinery that made a resize expensive in the first place. Take away the hourly rounding, the multi-year commitments and the discount tiers you have to model in a spreadsheet, and what is left is the boring truth: you rent a machine, you pay for the time you had it, you give it back.

The right call at 3am is to make the machine bigger and go back to bed.

Your pricing model should let you.