The engineering time cost of on-call incidents is usually measured in incident duration: how many hours from page to resolution. That metric is real and worth tracking, but it misses most of the actual cost. A two-hour 3am incident does not cost two hours. It costs that person's next morning, their focus on the following day's work, their confidence in the codebase, and, accumulated over months, a portion of their decision to stay on the team or look elsewhere.
This piece is about the costs that do not appear in your incident management dashboard. They are the costs that platform teams feel acutely but struggle to quantify, and that engineering managers often do not see until someone hands in their notice.
The direct cost is just the entry fee
Start with the obvious part. An on-call engineer paged at 3am is interrupted during sleep, spends time waking up and orienting, spends more time investigating, and eventually applies a fix or escalates. The mean time to resolution for a Kubernetes production incident that requires manual investigation is highly variable: some resolve in 10 minutes with a clear runbook, others take 90 minutes or more when the cause is not immediately obvious.
At competitive SRE compensation levels in growing engineering organizations, that 90-minute window represents material cost in billed labor. But that calculation is also the least interesting part, because it is the part engineers already track and managers already see in their MTTR charts.
The less visible cost begins after the incident closes.
Sleep fragmentation and the next-day tax
Sleep fragmented by a 3am page does not recover cleanly. A 90-minute incident from 3:00am to 4:30am leaves most people unable to fall back to sleep properly. They arrive at the next morning's standup operating on degraded cognitive resources, often without acknowledging it, sometimes without recognizing it themselves.
The work that gets done the day after an incident is shallower. Code review catches fewer issues. Design decisions rely more on pattern-matching and less on careful analysis. Subtle architectural trade-offs get glossed over. None of this shows up as a defect immediately. It shows up weeks later as a slightly wrong design choice, a missed edge case in a code review, an integration that works but has an obvious-in-hindsight flaw.
This is the next-day tax on incident response. It is real, it is measurable in principle, and it is almost never measured in practice because there is no field in the incident ticket for "hours of degraded cognitive function in the 24 hours following."
Remediation work as a form of attrition
On-call rotations where manual remediation is the norm create a specific type of fatigue that differs from general work fatigue. The problem is not just volume. It is that manual remediation is reactive, repetitive, and rarely leads to learning or growth. You are not building anything. You are running the same investigation steps, reading the same event logs, applying the same category of fix, and writing up the same post-mortem format.
Repetitive manual investigation is not just slow work. It is work that makes your best engineers start to wonder whether this is the right team for them.
Engineers who find themselves doing significant amounts of repetitive remediation work consistently report lower job satisfaction scores than engineers whose on-call work is dominated by novel problems and genuine automation improvements. This is not surprising. Most engineers chose the profession because they like building systems, not because they like running the same kubectl commands at 3am.
The practical consequence is attrition risk. It is not that a single incident causes someone to leave. It is that a pattern of high-frequency, high-friction, low-learning incidents shifts the cost-benefit calculation that every engineer is continuously making. When that calculation tips, you lose someone who has months or years of context in the system, and you spend the next six months onboarding a replacement who lacks that context.
The runbook gap that manual processes create
There is a common assumption that manual remediation is safer than automated remediation because humans apply judgment. That is true in one direction. A human does not blindly restart a pod during a database migration. A human recognizes when a runbook step does not apply to the current situation. The judgment capacity of a person with full context is real.
The problem is that manual processes do not scale evenly with team turnover. The judgment that makes manual remediation safe is institutional knowledge: who knows which services have quirky startup behaviors, who remembers that the payments namespace has a fragile PodDisruptionBudget that cannot tolerate concurrent restarts, who knows which nodes are running canary traffic.
That knowledge lives in people, not in runbooks. Runbooks capture the steps. They do not capture the exceptions to the steps. When the engineer who carries that context leaves the team, the runbook becomes less reliable. Manual remediation by a new engineer following the runbook is often riskier than it appears, because the runbook omits the judgment calls that the original author applied invisibly.
This creates a second-order cost: the runbook maintenance burden. To keep manual remediation safe as the team changes, someone has to continuously update the runbooks to capture the edge cases and exceptions. That work is unglamorous and easy to defer, so it is almost always deferred. The gap between what the runbook says and what an experienced engineer actually does grows over time.
What changes when investigation time shrinks
The argument for improving the tooling around on-call investigation is not primarily about the saved engineering hours in a single incident, though those savings are real. The more important argument is about what kind of work your on-call engineers end up doing.
If the investigation step in an incident takes 45 minutes to identify the responsible workload and propose a fix, your on-call engineer has spent those 45 minutes in a stressful, reactive, low-judgment state. If the investigation step takes 3 minutes because the tooling has already surfaced the root cause and a proposed fix, your engineer spends those 3 minutes reviewing a specific proposal and deciding whether it is correct given their context.
The second version is not just faster. It is a qualitatively different type of work. It is the work of exercising judgment on a specific proposal, which is the kind of work that engages rather than drains. The engineer is not running through a checklist hoping to find the problem. They are evaluating a diagnosis against what they know, which requires and rewards expertise.
Measuring the hidden cost without a perfect instrument
There is no clean metric for on-call burnout or next-day tax. What you can measure as a proxy: incident frequency and duration trends, number of incidents per on-call shift, the fraction of incidents that involve the same category of root cause (repeated CrashLoopBackOff from memory pressure, repeated HPA delays from the same deployment), and SRE team attrition rate compared to the broader engineering organization.
If your SRE attrition is higher than your broader engineering organization, and your incidents cluster around the same repeating categories, the problem is not that your engineers cannot handle the work. The problem is that the work is not worth handling in the current form. The hidden cost is high enough that it is showing up as departure decisions.
Improving the tooling around investigation does not eliminate on-call. It does not remove the need for human judgment in remediation decisions. But it reduces the fraction of on-call time spent in the low-value investigation phase, and it makes the remaining work more like the kind of work that keeps good engineers engaged with a platform they have spent months or years understanding.
That is not a small thing to improve, even if it does not show up cleanly in your MTTR numbers.