It's 03:20. The API is back up. The engineer who caught the 02:41 page writes a short Slack message, goes to bed, and wakes up six days later to a half-filled postmortem template with a timeline nobody trusts and three action items nobody owns. A week later the "postmortem" is a half-filled template with a timeline nobody trusts and three action items nobody owns. The incident happens again in six weeks.
That loop-page, fix, forget, repeat-is the actual cost center in on-call, and it is where AI is making the most measurable dent right now. Not in paging. Not in scheduling. In the paper trail.
What AI actually compresses in on-call work
The pitch is similar across the postmortem tools: 90 minutes of human reconstruction collapses to 15 minutes of human review. The honest framing is that these tools do real work, but most of them are summarizing artifacts that already exist. They are not investigating; they are transcribing. That's enough for many teams, especially those whose incidents are well-captured in their incident-channel chatter.
That distinction matters. When incident.io describes its Scribe feature, it claims to reduce documentation time by 75-85%, cutting postmortem work from 90 minutes to 15 minutes by auto-capturing commands, role assignments, and decisions in real-time. Rootly frames the same outcome slightly differently: by automatically capturing a detailed timeline and generating a post-mortem draft, AI ensures that this crucial learning step actually happens, transforming the post-mortem from a 90-minute chore into a 10-minute review.
Both claims are plausible. Both are also optimistic when the incident channel was a mess. It is not enough for teams whose incidents require deep investigation across systems-and that gap is what the agentic-investigation category is starting to fill.
There is also a consolidation angle worth tracking. PagerDuty's Postmortems feature was removed from the product in January 2026. Teams already invested in PagerDuty for alerting now need to evaluate whether to add incident.io for coordination, or migrate entirely to a unified platform.
Organizations with deep Atlassian investments face a similar choice given Opsgenie's April 2027 shutdown. The postmortem tool market is mid-consolidation, and whatever you pick now will have to carry postmortem generation as a first-class feature, not a bolt-on.
The handoff itself: the part AI hasn't fixed yet
Two practices do more to make on-call survivable than any tool: high-quality runbooks and disciplined shift handoffs. Both attack the same enemy-dependence on a single person's memory. A runbook turns tribal knowledge into a step-by-step procedure any on-call engineer can follow at 3am without paging an expert.
The shift handoff is the moment an outgoing engineer transfers not just the pager but everything in their head: which service has been flaky for three days, which deploy is half-rolled-out, which P2 they acknowledged but haven't closed. Formalizing the shift handoff as a short written ritual covering open incidents, flaky services, and in-flight changes-and setting an explicit ceiling on after-hours pages-are the two structural fixes that survive the most tool changes.
Most teams are still doing this by hand. One engineering manager described it plainly: "We have an on-call schedule in a Google Sheet. The problem is, nobody looks at it. When something breaks at 2 AM, everyone waits for someone else to speak up first. By the time someone actually responds, you've lost 20 minutes."
Rotating engineers through services they do not own increases MTTA because responders spend the first minutes of an incident just orienting themselves. A handoff note that says "payment-service has been throwing 502s intermittently since Thursday's deploy, watching it" is worth more than any alert threshold.
What GitLab does publicly shows the gap.
The outgoing SRE records their shift using a handover issue template and assigns it to the incoming SRE. A /sre-oncall [handover] Slack command creates a new issue and pre-populates outgoing/incoming handles, open/closed incidents, and resolved alerts.
That's a semi-automated template, not AI generation. The context that matters-the flaky service, the partially-rolled-back deploy, the customer conversation the team lead had this afternoon-is still hand-typed.
A teammate like Beagle can bridge part of this: watching the incident channel across the week, threading context into a draft handoff note, and surfacing it to the outgoing engineer 30 minutes before shift end for a quick edit and send.
Beagle in action#incidents, Friday 4:45pmWhere the automation boundary sits today
Here is the honest map of what is and is not automatable right now:
| Task | Automatable today? | Condition |
|---|---|---|
| Postmortem timeline reconstruction | Yes | Incident channel was active and structured |
| AI draft of postmortem narrative | Yes | Transcript quality determines output quality |
| Stakeholder update during incident | Yes | With a draft-and-approve human in the loop |
| Shift handoff note generation | Partially | Needs clean incident data; context is still hand-typed |
| Runbook execution for known patterns | Yes | For documented, repeatable incident types |
| Triage of novel incidents | No | Requires human judgment |
| Escalation decisions | No | Requires knowledge of team state, sleep schedules, context |
The model is shifting from "human investigates all alerts" toward "AI investigates, human approves"-but that second step, human approval, is non-negotiable for novel or high-severity events.
Labor and leverage live on different schedules. The labor is due now; the leverage shows up months later, as an incident that did not happen. Teams under pressure cut the labor. AI closes the gap-less labor for the same leverage, which makes the postmortem survive the 2am reality.
The non-obvious consequence: the Verica Open Incident Database, cataloging approximately 10,000 incidents from 600+ organizations, found that only about 25% of public incident reports clearly identify a root cause-a useful corrective to the "we reduced MTTR by X%" claims that pepper vendor marketing. Better postmortem tooling does not automatically mean better root-cause analysis. It means faster drafts. Whether those drafts contain real insight depends on what the incident channel captured.
AI on-call handoff: common questions
What does AI actually automate in the on-call postmortem process?
AI postmortem tools-incident.io Scribe, Rootly AI Copilot, FireHydrant AI Retrospectives-automate timeline reconstruction from Slack transcripts, PagerDuty events, and deploy logs. The output is a structured draft a human reviews, not a final document. They reduce authoring time from roughly 90 minutes to 15, but depend on incident-channel quality.
Does AI automation improve MTTA?
Not directly. MTTA (mean time to acknowledge) is a scheduling and alerting problem. For critical systems, the goal is to keep MTTA under 5 minutes; high MTTA signals alert fatigue or schedule coverage gaps -not postmortem quality. AI helps after the incident closes, not at the moment of the page.
What's the biggest gap in on-call automation right now?
The shift handoff note. Postmortem tools read backward from a resolved incident. Handoff notes read forward into the next shift-they need to surface in-flight issues, flaky services, and ambient context that never became a formal incident. That data exists across threads and channels, but no mainstream tool assembles it automatically yet.
How does PagerDuty's January 2026 postmortem sunset affect teams?
PagerDuty removed its Postmortems feature in January 2026. Enterprise Incident Management customers can now create post-incident reviews in Jeli instead. Teams relying on PagerDuty for the full incident lifecycle need to either adopt Jeli or move postmortem work to a dedicated platform like incident.io or Rootly.
Is automating the postmortem worth it for small teams?
For a 7-engineer team running one incident per week, documentation alone costs roughly $50,000 per year in engineer time-just for writing reports, not fixing incidents or preventing them. Even a 60% reduction pays for the tooling many times over. The threshold is lower than most teams assume.