Zero human escalation is the wrong objective for an on-call team. A pager that never wakes anyone can indicate excellent automation, or it can indicate that the organization has stopped noticing important failures. The more useful standard is stricter: production should escalate only when a human decision is genuinely required.
That distinction changes how incident response is designed. It shifts attention away from the raw number of pages and toward the quality of each escalation. It asks whether an incident has been detected early, diagnosed with enough confidence, and either resolved safely or advanced to the point where human judgment has real value.
At Cordant, we think of this as escalation intelligence. Our autonomous SRE agent watches production systems, diagnoses incidents as they start, and proposes or applies a fix. The intended result is not a world without on-call engineers. It is an on-call rotation reserved for decisions that systems should not make alone.
Why “zero escalation” is an incomplete metric
Zero escalations sounds like a clean operational target. It is easy to put on a dashboard and easy to repeat in a planning meeting. But the metric hides two very different outcomes.
In one outcome, an organization has strong detection, reliable remediation, and clear controls. Incidents are handled before they affect customers, and genuinely ambiguous or high-impact events reach an engineer. In the other, alerts are suppressed, thresholds are too conservative, ownership is unclear, or the team has learned to tolerate silent degradation. Both outcomes can produce a quiet pager.
That is why pager volume alone is a weak measure of reliability maturity. A better set of questions includes:
- What proportion of alerts represent actionable incidents?
- How often does an automated diagnosis lead to a correct remediation?
- How much time passes between the first meaningful signal and acknowledgment?
- How often are engineers woken for an event that required no human decision?
- When a human is paged, is the context sufficient to make the next decision quickly?
The last question matters especially. An escalation is expensive not only because it interrupts sleep or focused work. It is expensive when the engineer must reconstruct the incident from scattered logs, dashboards, deploy histories, and chat messages before deciding whether anything needs to happen.
Escalation should represent a decision boundary
An alert is a signal. An escalation is a request for judgment. Treating those as interchangeable creates a large amount of avoidable pager load.
A useful escalation policy therefore needs more than severity labels. It needs a human judgment threshold. Before waking someone, the system should be able to answer several questions: What is failing? How confident is the diagnosis? What action is available? What is the likely impact of that action? Is the action reversible? What happens if no human responds immediately?
Consider a SaaS order-processing service that begins returning elevated errors after a configuration change. Cordant might correlate the errors with the change, inspect the affected dependency, and identify a rollback as the lowest-risk action. If the rollback is authorized, reversible, and restores the relevant SLO, the system can apply it and record the incident without waking the primary on-call engineer.
Now change the circumstances. The errors affect only a subset of high-value orders, the dependency is shared with another critical workflow, and the proposed rollback could discard valid state. The technical symptoms may look similar, but the decision boundary has moved. A human should be involved because the remediation requires judgment about business impact and risk, not because the monitoring system failed.
This is the operational meaning of only-meaningful-escalations. Automation handles the known and bounded cases. Humans handle ambiguity, competing priorities, novel failure modes, and actions whose consequences exceed the system’s authority.
What this changes for on-call design
Reducing unnecessary escalations is not primarily a paging configuration exercise. It affects alert taxonomy, runbook quality, incident severity tiers, and the design of the on-call rotation.
Alert taxonomy should distinguish an observation from a condition that requires intervention. A transient increase in latency may warrant diagnosis. A confirmed SLO breach with a known, safe remediation may warrant automated action. A breach with uncertain scope or an irreversible recovery path may warrant escalation. These are different states, even if they begin with the same metric.
Runbooks also need to be written as decision systems rather than static documents. A useful runbook describes the evidence that supports a diagnosis, the actions that are safe to automate, the conditions that should stop automation, and the information a human needs when escalation occurs. That structure makes it possible to automate parts of response without pretending every incident is predictable.
The on-call rotation benefits in a less obvious way. If engineers are woken only for consequential decisions, the meaning of a page improves. A page becomes more trustworthy. That can reduce signal fatigue and improve mean time to acknowledgment because the recipient is less likely to assume that the event is another false positive.
There is also a cultural effect. Engineers can spend less time proving that alerts are noisy and more time improving the boundaries around automation. The question becomes, “What evidence would let us handle this safely without a human?” That is a more productive design conversation than simply asking how to lower the alert count.
The boundary: humans still own the hard decisions
The distinction matters: zero escalation as a headline goal and only-meaningful-escalations as an operational target are not the same thing. The first can encourage organizations to optimize for silence. The second preserves a deliberate role for human judgment.
Zero human escalation does not mean removing humans from incident response. It does not mean allowing an autonomous system to change production without controls, hiding uncertainty behind a confidence score, or treating every remediation as safe because it worked once. It does not mean eliminating the on-call rotation, abandoning incident review, or accepting a lower standard of reliability.
It also does not mean every automated action should be judged solely by whether service was restored. A quick fix that creates data integrity problems is not a successful resolution. Evaluation has to include the quality of the diagnosis, the safety of the action, the reversibility of the change, and whether the system escalated when its assumptions no longer held.
For that reason, autonomy should be bounded. Teams need explicit permissions, audit trails, rollback paths, suppression controls, and escalation triggers. They need to know which incident severity tiers can be handled automatically and which always require a human. They need a way to review near misses, including incidents that were resolved without a page but came close to crossing a safety boundary.
The counterpoint: some interruptions are worth keeping
There is a legitimate risk in pursuing fewer escalations. Teams can become so focused on reducing pager load that they make escalation difficult by design. A system that waits for perfect certainty may page too late. A system that requires every signal to be correlated may miss a novel incident. A system that applies a fix automatically may reduce visible symptoms while allowing a deeper failure to spread.
Good escalation intelligence must therefore account for uncertainty, not eliminate it. Low confidence can itself be a reason to escalate when the potential impact is high. A new failure pattern may deserve human attention even if the blast radius is still unclear. A service with incomplete observability may need a more conservative policy than a service with strong telemetry and tested recovery actions.
The right question is not whether an automated system can explain every event perfectly. It is whether the system can recognize when its explanation is insufficient for the action under consideration. That requires calibrating the false positive rate against the cost of missed incidents, rather than chasing either metric in isolation.
In early deployments with design partners, this philosophy leads to practical choices. Start with incident classes that have clear signals and reversible remediations. Keep humans close to unfamiliar or high-consequence actions. Measure not only pages avoided, but also correct diagnoses, successful repairs, prevented escalations, and cases where the system appropriately stopped and asked for help.
A quieter pager, with more meaning behind it
The strongest on-call program is not the one that can claim nobody was paged. It is the one where every page has earned its interruption. Engineers should be able to trust that an escalation reflects a real decision, not merely a threshold crossing that an automated system could have understood and handled.
That standard is harder than “zero escalation” and more useful. It treats reliability as a partnership between automated response and human accountability. Systems can absorb repetitive diagnosis and bounded repair. People remain responsible for intent, tradeoffs, exceptions, and consequences.
If your on-call rotation wakes engineers more than it needs to, Cordant is built around a different question: which incidents can be diagnosed and repaired safely, and which ones truly require your team’s judgment?