A team is paged eleven times a week and morale is poor. What do you do first?
Show the full answer Hide the answer
What is being tested
Whether you treat page volume as architectural evidence rather than as a rota problem, and whether you act on the sustainability issue immediately.
First, the immediate triage
Audit every alert from the last month and classify it:
| Category | Action |
|---|---|
| Fired, no action taken | Delete it. This is noise. |
| Fired, action was "wait and it recovered" | Delete, or convert to an auto-remediation |
| Fired, action could have waited until morning | Downgrade to a ticket |
| Fired, urgent action required | Keep — this is a real page |
In most teams with eleven pages a week, the majority are in the first three rows. Deleting them is not a compromise on reliability; it is a precondition for it. An alert that does not lead to action trains the team to disregard alerts generally, and the one that mattered will be missed.
Target: no more than about two pages per shift. Beyond that the responder cannot recover between them, and alert quality collapses because nobody has time to fix the underlying causes.
Second, protect the people
Sustainability is not a later concern. Check the rotation size — fewer than six or seven people makes it punishing, which drives attrition, which makes it smaller. Check that time is compensated. Check whether one person is being contacted outside their shift because they are the only one who knows how things work; that hero is a single point of failure with a name and a family.
Third — and this is the architectural finding
Eleven pages a week is telling you something about the system. After the noise is removed, whatever remains is evidence. Group the genuine pages by cause:
- Capacity-related → insufficient headroom, or autoscaling that reacts too slowly.
- Dependency-related → missing timeouts, bulkheads, circuit breakers or fallbacks; a slow dependency should degrade, not page.
- Deployment-related → inadequate canaries, missing automated rollback.
- Recurring known issue → nobody has been given time to fix the cause, which is a prioritisation failure rather than a technical one.
- Manual toil → something that pages a human to do a thing a script could do.
Each category has an architectural remedy, and treating page volume as a rota problem is how it persists for years.
The feedback loop this reveals
Teams that own what they build have a direct incentive to make it reliable — the loop between a design decision and being woken by it is what "you build it, you run it" is actually for. A high page rate means either that loop is broken (a different team built it) or that the team has not been given the time to close it.
If it is the second, that is a conversation with leadership, and the page audit is the evidence to bring.
What good looks like afterwards
Every page is actionable and urgent. Every page has a runbook, so it does not require original thought at 3am. The person paged can actually fix it — access, permissions and knowledge. Handover between shifts exists. And there is a standing follow-up loop, so a page that recurs generates work rather than resignation.