Best Automated Post-Mortem Tools: 9 Checked, 1 Real AI Draft

The best automated post-mortem tools in October 2026 are incident.io, Rootly, Datadog Incident Management, PagerDuty Post-Incident Reviews, FireHydrant, Atlassian Jira Service Management, Xurrent IMR and Grafana IRM among commercial products, and Aurora SRE in open source. Each writes a first draft, not a finished post-mortem (Grafana IRM writes only a summary): they fill the summary, timeline, root cause and suggested follow-ups from the incident channel, call transcripts, alert data or (in Aurora's case) the investigation an AI agent ran. A person still has to supply the human timeline, the business impact and an owner for each action item. Pick the tool that reads where your incident evidence actually lives.

Two dates matter right now. PagerDuty's legacy Postmortems feature reaches end of life on October 31, 2026, and Jeli reaches end of life on December 22, 2026; both move to Post-Incident Reviews in PagerDuty's web UI (release notes).

Below: one real AI-written incident report from our lab, marked up with what it got right and what a person would still have to write, then the nine tools, each checked on the vendor's own site or docs on 2026-10-21. Arvo AI builds Aurora; we have not used the eight commercial tools, and nothing below claims we did.

What does an AI-drafted post-mortem actually look like?

We run an open lab, Arvo-AI/aurora-lab: a small app (shop: nginx frontend, Python api, worker, redis, load generator) on a 3-node kind cluster, 19 faults we inject on purpose, and Aurora investigating each one from the alert text alone. Every run saves Aurora's written report (aurora-rca.md), every command it ran and the grade. Arvo wrote the scenarios. Across the 38 graded runs on 2026-10-02, Aurora's root cause was correct in 34 and partial in 4; a judge model graded each answer against the injected fault, a person read all 38 grades, and a blinded regrade agreed with all 38. The full table, including HolmesGPT and K8sGPT, is on /benchmark.

The run below is scenario 13, run 1 (files). We applied a NetworkPolicy that lets only app=worker pods reach redis, so the api's redis calls time out and the frontend returns 5xx. Aurora got this text and nothing else:

HighErrorRate [critical] namespace=shop service=frontend: 100% of requests to /api/ returned 5xx over the last 5 minutes (threshold 5%). Cluster: aurora-lab (kubeconfig). Investigate and find the root cause.

It made 25 tool calls in 202 seconds, for $0.69 in model cost: 19 read-only kubectl commands, plus listing the incident and the connected cluster and reading and writing its own memory notes. Then it wrote this. It is reproduced in full and unedited; the bracketed numbers point to saved command outputs.

## Incident Report

**What Happened**
A critical "HighErrorRate" alert fired for namespace=shop, service=frontend at 2026-10-02T20:24:46 UTC. At the time of investigation, the shop namespace had just bootstrapped — all pods were Running but only ~73 seconds old, indicating a full cluster/deployment restart [4, 5]. Frontend nginx logs showed continuous `GET /api/items` requests returning 502/503 [7], and the backend `api` pods showed the request pattern `connected to redis at redis:6379` followed by `request failed: redis error: timed out` and `GET /items HTTP/1.0 503` repeating continuously rather than as a one-time startup blip [8].

**Root Cause**
The root cause was a NetworkPolicy named `redis` in the shop namespace, created at 2026-10-02T20:23:54Z, which restricts ingress to redis:6379 to pods labeled `app=worker` only [20, 22]. The `api` pods are labeled `app=api`, not `app=worker` [23], so their connections to redis were silently dropped by the policy, causing the client-side 2-second socket timeout defined in the api code [14] to be hit on every request, producing the `redis error: timed out` → 503 response from the api, which cascaded into 502/503 responses from the frontend's `/api/items` proxy [7, 8]. Redis itself was healthy throughout — clean startup logs, Ready=True, and negligible CPU/memory usage (3m/4Mi) with no error output [10, 11, 12] — ruling it out as the failing component. The first observed 503 occurred within ~2 seconds of the NetworkPolicy's creation timestamp, consistent with (though not independently proof of) the client timeout window configured in the api code [22, 14].

**Impact & Timeline**
The policy was created at 20:23:54Z, shortly after cluster bootstrap, and the alert triggered at 20:24:46Z [20, 22]. Both `api` replicas (api-f64486c4c-2nqsk, api-f64486c4c-mvpnl) [4, 23] were affected, resulting in 100% failure of `/api/items` calls proxied through the frontend service [7, 8]. The issue was ongoing and had not self-resolved as of the time of investigation.

## Ruled Out
- Redis overload or crash — redis-59458f55d8-n6glm showed clean startup logs, Ready=True, and minimal resource usage (3m CPU / 4Mi memory) with no errors [10, 11, 12].
- Node-level resource contention (including worker pod's buffer-allocation churn) — `kubectl top nodes` showed both worker nodes at ~0% CPU and ~1% memory [16].
- Transient startup/readiness probe noise — frontend/api 5xx logs showed continuous, non-improving failures rather than a one-time startup blip [7, 8].

## Not Checked
- Whether the worker pod genuinely requires redis access (its code only allocates and frees buffers, per the api-code configmap) — flagged as a service-owner design question rather than part of the required fix, not independently verified against worker source code beyond what's in the configmap.
- CNI-level or lower-level network diagnostics beyond the NetworkPolicy object itself — not needed once the policy rule was identified as sufficient explanation, and not accessible in read-only mode.
- loadgen pod's traffic pattern/configuration — retrieved as YAML [19] but not analyzed in depth, since the mechanism was already isolated to the NetworkPolicy rule.

Aurora also attached one suggested fix, separate from the report, rated low risk:

kubectl patch networkpolicy redis -n shop --type='json' -p='[{"op":"add","path":"/spec/ingress/0/from/-","value":{"podSelector":{"matchLabels":{"app":"api"}}}}]'

That patch was never run: the lab does not apply fixes. It changes the cluster, so in a real incident a person would apply it, then confirm with kubectl describe networkpolicy redis -n shop. To roll it back, remove the added from entry (or reapply the original policy from version control). The NetworkPolicy runbook walks through this fault from first symptom to fix.

What the AI draft got right

• The root cause, with proof. The policy name, its creation time, the app=worker rule and the app=api label on the failing pods, each tied to the command output that shows it. The grade was correct, and a person confirmed it.
• What it ruled out, and why. Redis was healthy (logs, readiness, 3m CPU and 4Mi memory), and the nodes were idle. Most human post-mortems skip this section, and it is the one that stops the next responder from chasing the same dead ends.
• What it did not check. The "Not Checked" section is honest: no CNI-level diagnostics, and the load generator was read but not analyzed.

What it got wrong

An AI reviewer that rechecked the report against the raw output flagged two claims, and we confirmed both in the saved logs:

• "Indicating a full cluster/deployment restart" is an over-reading. The pods were 73 seconds old because the lab redeploys the app before every run. Anyone who knows the environment would strike that line; the model did not know the environment.
• "100% failure of /api/items calls" is not quite true: one api pod's log shows "GET /items HTTP/1.0" 200 before the policy took effect.

Neither error touches the root cause, and this pattern holds across the lab: the AI review found claims the evidence did not support in 15 of the 18 reports for the harder scenarios, none of them in the root cause (REPORT.md). The worst case is scenario 12, where two faults ran at once. In both runs Aurora found the one the alert named (graded partial) and wrote a line saying the rest of the namespace was fine; run 1 put it as "Other workloads in the shop namespace (api, frontend) remained healthy and unaffected", with pod status as its only evidence. The frontend Service was selecting no pods. Paste that into an Impact section and the post-mortem states, wrongly, that there was no second outage.

What a human would still have to add

The machine-written parts are the parts a machine can observe. Everything that depends on people (decisions, intent, customer impact, who owns the follow-up) has to come from the people, and any tool that fills those sections without a source for them is guessing. Atlassian's own docs say the same about its drafts: validate "the technical findings, root cause statements, contributing factors, business impact, action items, and owners" before publishing (Atlassian).

How Aurora turns that report into a post-mortem

The report above is the input to Aurora's post-mortem step. The built-in "Generate Postmortem" action is on by default and runs when an incident is resolved. It starts a background agent session with the incident fields and the first 4,000 characters of this report (this one is about 3,200, so it goes in whole), tells it to read the Slack channels for the incident window if Slack is connected, and asks for a document with Summary, Timeline, Root Cause, Impact, Contributing Factors, Resolution, Action Items (as checkboxes) and Lessons Learned, with "no speculation beyond what data supports" (postmortem_action.py). The session runs in agent mode with the org's other connected tools available, but the instructions point it only at the report and Slack. The document is versioned and editable, and can be regenerated.

Our lab incidents are never marked resolved and have no Slack channel, so the lab did not run this step, and we have not measured what it writes from a report alone. What the code tells you: with no Slack, the instructions leave the report as the only named source for the Timeline, Impact and Contributing Factors sections, so expect them to inherit both its strengths and the two overstatements above.

Which tools generate post-mortems automatically after an incident?

Prices are the vendors' published list prices on 2026-10-21, in US dollars.

The 9 automated post-mortem tools, one by one

incident.io

• What the AI drafts: "AI that writes the first draft for you, pulling from your timeline, Slack or Teams conversations, and investigation data." It can also review a finished document and suggest inline edits, or redraft a section (docs).
• Export: Google Docs, Notion, Confluence or SharePoint, or announce it in Slack.
• Pricing: AI features are on Pro and Enterprise (AI post-mortem docs); Pro is $25 per user a month and Scribe call transcription is Pro and Enterprise only (pricing). For private incidents, AI works only if your organization opts in to sending private incident data to AI subprocessors.
• Fit: teams that run incidents in Slack or Teams and want drafting plus review in one editor. See the incident.io alternative guide.

Rootly

• What the AI drafts: AI blocks in a template draft "summary, impact, root cause, mitigation, and a curated timeline, generated from the incident's data, Slack channel, and call transcripts", each steerable with custom instructions (retrospectives).
• Export: Confluence, Notion, Google Docs and SharePoint. Action items push to Jira or Linear as subtasks with owners and status kept in sync.
• Pricing: Incident Response is $20 per user a month, and "AI Scribe and Retrospectives" are listed as always included (pricing). This changed since our July version of this page, which said the AI tier was contact-sales; that is now true only of Rootly AI SRE, the investigation product.
• Fit: the most editorial control over each AI section, with AI drafting in the base Incident Response price. See the Rootly alternative guide.

Datadog Incident Management

• What the AI drafts: post-mortem templates take AI variables powered by Bits AI: executive summary, system overview, key timeline, customer impact, action items and lessons learned. Datadog suggests a value for each that you accept, edit or reject, and ships an out-of-the-box "General incident with AI content" template. The incident timeline must contain at least 10 messages before the AI variables generate anything (templates).
• Export: Datadog Notebooks, Confluence or Google Drive (post-mortems).
• Pricing: Incident Management is $30 per seat a month billed annually, $36 month to month (pricing).
• Fit: teams whose evidence already lives in Datadog. Note the AI writes a "customer impact" section from incident data; check it against the gaps in the table above. Investigation itself is covered in the Datadog Bits alternative guide.

PagerDuty Post-Incident Reviews (and the Jeli deadline)

• What the AI drafts: "Generate with AI" pulls from up to three sources, the Scribe Agent, Slack messages from the incident channel and incident lifecycle events, and writes each section of the review, narrative markers and follow-up actions. If Scribe was not on the call, the draft uses whatever sources exist (docs).
• Export: an HTML share link or a PDF. Follow-up actions can become Jira tickets, with status synced both ways on the Jira Forge app 4.0 or later.
• Pricing and availability: Post-Incident Reviews in the web UI, including AI-generated drafts, became generally available on August 27, 2026, on Professional plans and above; the AI drafts are for PagerDuty Advance customers (release notes). An October 20, 2026 release added a "Post-incident review on resolve" setting.
• The deadlines: PagerDuty's legacy Postmortems reach end of life on October 31, 2026 for all customers, with existing data downloadable before then. Jeli reaches end of life on December 22, 2026; PagerDuty said it would send details on migrating Jeli review data before that date. If you run either, the replacement is already in your account. See the PagerDuty alternative guide for the investigation side.

FireHydrant (now part of Freshworks)

• What the AI drafts: retrospective drafts created when an incident is resolved, with timeline, root cause analysis, contributing factors and suggested action items with priorities, plus Zoom and Google Meet transcription (FireHydrant AI).
• Export: PDF, Google Docs, Confluence or a direct link (docs).
• Pricing: FireHydrant AI (summaries, meeting transcripts, triage, retros and follow-ups) is listed only under Enterprise (custom price); Pro is $25 per responder a month billed annually, without it (pricing).
• Ownership: FireHydrant absorbed Blameless in August 2024, and Freshworks closed its acquisition of FireHydrant on January 5, 2026, saying it is integrating FireHydrant with Freshservice. If you are looking for a FireHydrant alternative after the acquisition, the dedicated options on this list are incident.io and Rootly; see also the FireHydrant alternative guide.

Atlassian Jira Service Management

• What the AI drafts: two levels. Atlassian Intelligence "can automatically generate an incident summary" for a post-incident review, on Premium and Enterprise plans (docs). The newer Incident Command Center, in an early access program on Premium and Enterprise and with Rovo enabled, has a "Generate PIR" button that turns the incident record into a full first draft (docs).
• Export: create a PIR work item, or copy the draft to another tool.
• Fit: teams already tracking incidents in Jira. The docs tell you to "add or refine" the root cause, impact, follow-up actions, "owners, and due dates" yourself, which matches what we saw in the lab.

Xurrent IMR (formerly Zenduty)

• What the AI drafts: "Xurrent's AI compiles postmortem reports automatically from logs, metrics, and Slack or Teams conversations, following your preferred templates" (product page).
• Export: Markdown or PDF.
• Pricing: Starter $6 and Growth $16 per user a month billed monthly ($5 and $14 annually); Enterprise on request (pricing). The plan comparison table lists Postmortems under AI features with a check on Starter, Growth and Enterprise; the product page does not say how the AI draft differs by plan.
• Fit: the lowest entry price, with thin export targets.

Grafana IRM

• What the AI drafts: a post-incident summary, not a full post-mortem. The OpenAI integration sends "a sanitized version of the incident timeline" to the OpenAI API and returns a summary, a timeline of events and the actions taken, which you edit before saving. You need your own OpenAI account, organization ID and API key. Grafana's own note: "AI-generated summaries may occasionally produce inaccurate or incomplete information" (docs).
• Fit: worth turning on if you already run Grafana IRM; not a reason to adopt it.

Aurora

• What the AI drafts: the full document described above, from Aurora's own investigation report plus Slack context, with all eight sections. The difference from the tools above is the input: the root cause section rests on commands the agent ran and cited, not on what people typed in the channel.
• Export: Confluence and Notion from the post-mortem view, or a Markdown download; SharePoint through the agent's SharePoint tool. No Google Docs export.
• Pricing: open source under Apache 2.0 and self-hosted; you pay for infrastructure and model tokens. In our lab the investigation that produces the report cost a median $0.35 per run; the post-mortem step's own cost was not measured.
• Watch out for: Aurora is an investigation agent that also writes post-mortems, not a retrospective editor, and it has no on-call, paging or status pages. If your incidents are resolved in chat and you only want drafting, one of the tools above fits better.

Checked and left off. Better Stack's AI SRE page advertises "AI written post-mortems" from the incident timeline and Slack, but its post-mortem docs describe only a Markdown comment you write yourself, so we could not confirm how it works. Keep, which shows up in searches for open source incident automation, is an alert management and AIOps platform (deduplication, correlation, workflows), MIT-licensed outside its ee/ directory, and Elastic announced an agreement to acquire it in May 2025; it does not write post-mortems. The Keep vs Aurora comparison covers the difference.

Which tool should you choose?

Choose by where the facts of your incidents are recorded, because a drafting tool can only summarize what it can read:

1. Incidents worked in Slack or Teams and on calls: incident.io or Rootly. Rootly includes AI retrospectives at $20 per user; incident.io needs Pro at $25. The incident.io vs Rootly comparison goes further.
2. Everything is already in Datadog: Datadog's AI template variables, as long as your incidents have at least 10 timeline messages.
3. You are on PagerDuty or Jeli: move to Post-Incident Reviews before October 31 (legacy Postmortems) or December 22 (Jeli), then decide whether PagerDuty Advance is worth it for the AI drafts.
4. Incidents tracked in Jira Service Management: Atlassian's PIR drafts keep the review next to the tickets.
5. The root cause is found in the infrastructure, not in the channel: an investigation agent writes a better root cause section than a chat summarizer, because it has the command output. Aurora is the open source option; read its report the way you would read a new colleague's, and expect to fix the impact section.

Whatever you pick, budget the human part: the incident lead still writes the timeline of decisions, the impact and the owners, and that is what turns a draft into a post-mortem someone will act on. For the method rather than the tools, see automated post-mortem generation; for the investigation side, the AI incident investigation tools list and the Aurora lab report.

Aurora is open source on GitHub; to see the investigation and post-mortem flow on your own stack, book a demo.

Verified 2026-10-21: vendor pages and docs as linked. Lab files from Arvo-AI/aurora-lab, run v1-run1, scenario 13, run 1 (2026-10-02). Aurora behavior from the Aurora repository main branch.