There is a gap in incident response that gets almost no attention, and it sits in an awkward place.
It is not detection. Monitoring is good now. It is not diagnosis either, which is where most of the recent effort has gone and where it has genuinely paid off.
It is the bit in between finding the answer and somebody acting on it.
An investigation can produce a correct, well evidenced conclusion at 3:14 in the morning and it changes nothing at all until a person who can act on it is awake, has read it, and has said so. Everything before that moment is preparation.
The number that should bother you
Mean time to acknowledge is the metric for this, and it is the least discussed of the three.
Industry benchmarks put the median MTTA at 8 to 15 minutes, against a healthy target of under five. For high severity alerts, anything above roughly 15 minutes is usually read as a signal that something is wrong with the rotation or with trust in the alerting itself.
Then there is the reason behind it, which is worse. The 2026 State of Production Reliability Report found that 83% of on-call engineers ignore or dismiss alerts at least occasionally, and that 57% of on-call teams say fewer than 30% of their alerts are actionable. Analysis across more than a million production alerts found 60 to 80% required no human action at all.
The behavioural consequence is the part that matters. After six months of high page volume, engineers start acknowledging night pages 10 to 30 minutes late, or missing them entirely. Sixty-two per cent report weekly sleep disruption, and the rational response to that is to silence the phone overnight.
So the real P1 arrives into a system where the human has already, sensibly, stopped listening.
Better diagnosis does not solve this
Here is why I think this deserves separate attention rather than being folded into the general push for smarter tooling.
Suppose your investigation is excellent. It fires within seconds, checks the right systems, forms a hypothesis, tests it, and produces a conclusion with evidence attached. Genuinely good work, and faster than a person would manage.
Now it writes that conclusion into a channel at 3:14am.
Nothing about the quality of that conclusion changes when it gets read. The delivery is a separate system with separate failure modes: the phone is on silent, the page went to someone who moved teams, the primary did not respond and there was no secondary, the notification went to email because that was the default.
Improving the investigation makes the report better. It does not make anybody read it.
I find this clarifying, because it means the two halves are genuinely different engineering problems and you can be excellent at one while being poor at the other. Most teams I have seen are.
What the handoff actually needs
Three things, and only one of them is about speed.
It needs to reach the right person. Not the rotation, the person who can act on this specific thing. Those are frequently different, and every hop between them is dead time while the alert sits unactioned with somebody who is going to forward it.
It needs to escalate on silence. The most common failure is not a wrong recipient, it is no recipient. A page that goes out once and is never followed up is a page that depends entirely on one person being awake. Silence has to be treated as a failure state that triggers something, rather than as an outcome.
It needs to arrive somewhere the person will actually see it. A Slack message at 3am is a message nobody reads until morning. This is the part that gets treated as a detail and is not one. The channel has to match the severity, which means a critical page belongs on something that overrides a silent phone, and a low priority one belongs somewhere it will not.
None of that is intellectually difficult. It is just infrastructure that most teams have partially, in a form that was configured once and has drifted since.
Where Shankh sits
This is the problem Shankh is built for, and it is deliberately a separate thing from the investigation.
Vörr works out what is wrong. It reads the code, the cloud, the pipelines and the monitoring, and it produces a diagnosis with the evidence attached. Shankh takes that diagnosis and gets it to a human, on the channel that suits the severity, and keeps escalating until somebody acknowledges.
WhatsApp, a phone call, SMS, email, Slack. The channel choice is not a convenience feature, it is the difference between a notification that competes with a silenced phone and one that does not.
The reason I like this as an architecture, rather than as a feature bolted onto an investigation tool, is that it treats acknowledgement as the completion condition. The incident is not handled when the analysis is finished. It is handled when a named person has said they have it.
That is a higher bar than most tooling sets for itself, and it is the correct one, because it is the bar the business is actually using.
The part that connects the two
There is a reason these belong together rather than being two products you buy separately.
An escalation is only as good as its understanding of who should receive it, and that understanding is the same understanding the investigation needed. Which service this is. Which team owns it. How critical it is. Whether this is production or staging.
If the escalation layer has to be told that separately, in its own configuration file, then you now have two descriptions of your organisation that can disagree with each other. And they will, quietly, starting the first time somebody changes teams.
Sharing that context means the diagnosis and the page are drawn from the same picture. The alert reaches the owning team because the system already knew who owns it, not because someone maintained a routing table.
What I would look at
Measure your MTTA separately from your MTTR, and look at the overnight figure on its own. The daytime average will hide it.
Count how many of your pages go to a rotation rather than to a person, and how many require a forward before anybody can act.
Check what happens on silence. Not what the policy says happens. Test it, at an inconvenient hour, and find out whether the second hop actually fires.
Then look at how much of your recent MTTR was analysis and how much was waiting. If the second number is larger, more investigation capability will not help you. You have a delivery problem wearing a diagnosis problem's clothes.
Author note
The thing that changed my thinking here was realising I had been treating the page as the end of the automated part and the beginning of the human part, as though it were a clean boundary.
It is not a boundary. It is the least reliable link in the whole chain, and it is the one we have automated least.
Mohan Gopi, Associate DevOps Engineer at Frigga Cloud Labs, working across AWS, GCP and Azure. LinkedIn if your on-call setup handles this better than ours did.