On-call pain as an architecture metric: the shape that holds up

A pattern earns its keep by being cheaper to apply than to argue about. This one has survived energy metering and four other sectors that share none of the same vocabulary, which usually means the shape is real and not a coincidence.

How often people get woken up is a measurement of the system, not of the rota. Treat it as feedback on the design and it becomes the most honest quality signal you have, because unlike most metrics nobody can argue with it.

WHERE THE PAGES CLUSTER

Count pages by component over a quarter and the distribution won't be flat. Two or three things will account for most of them, and they'll be the components everyone already avoids. That list is your architecture backlog, ordered by evidence rather than by opinion.

It's also the most persuasive artefact we know for getting remedial work funded. "This module woke someone up eleven times last quarter" survives a prioritisation meeting in a way that "this module is badly designed" does not.

THE TWO KINDS OF ALERT

Some pages mean a human decision is required now. The rest mean something the system should have handled itself, or something nobody needed to know until Tuesday. Sorting a quarter's pages into those two piles is a couple of hours and reliably uncomfortable.

Anything in the second pile is either automation you haven't written or an alert that should be a report. Both are fixable, and both are usually cheaper than the ongoing cost of the interruption.

It paid for itself the first time a timezone change silently duplicated an hour of consumption. Because the structure was already there, recovery was a query instead of an investigation, and settlement analysts heard it from the system rather than from a customer.

IT DECIDES WHO YOU CAN HIRE

Bad on-call is a retention problem before it's an engineering one, and it compounds: the people who leave are the ones with options, which are the ones who could have fixed it. That's worth naming explicitly when a client asks why we want to spend a sprint on reliability.

The inverse holds too. A rota that's genuinely quiet is a strong signal about a codebase, and it's one of the few things about engineering culture that's hard to fake in an interview.

At a distributed generation operator it turned a recurring escalation into an ordinary state the system could describe. Several million reads a day went through without a single manual reconciliation, which hadn't been true of any quarter before it.

WHERE IT GOES WRONG

• Alerts that require no immediate decision, firing at 3am for six months.
• No page-per-component numbers, so remedial work competes with features on vibes alone.
• Losing the engineers with options, who were the ones who could have fixed it.
• Rebalancing the rota instead of fixing the two components generating most of the pages.

Count pages by component. That list is your architecture backlog.

WHEN TO REACH FOR IT

It's cheap on day one and expensive to retrofit, which makes it a default rather than a decision. We put it in the first commit and haven't regretted it yet.