--- title: "Incident Post-Mortem: review, setup & limitations · Undominated.ai" canonical: https://undominated.ai/skills/github-incident-postmortem/ description: "Walks a team from incident metadata through a reconstructed timeline, blameless 5-Whys root cause, quantified impact and owned action items, into a complete postmortem document with a common-mistakes table." --- # Incident Post-Mortem: review, setup & limitations · Undominated.ai > Walks a team from incident metadata through a reconstructed timeline, blameless 5-Whys root cause, quantified impact and owned action items, into a complete postmortem document with a common-mistakes table. [← Explore all skills](/skills/) PLANNING AND DELIVERY / GitHub community # Incident Post-Mortem Walks a team from incident metadata through a reconstructed timeline, blameless 5-Whys root cause, quantified impact and owned action items, into a complete postmortem document with a common-mistakes table. [See setup guidance ↓](#setup)[Original source ↗](https://github.com/github/awesome-copilot/tree/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem) SOURCE REVIEW Reviewed 2026-10-15 Evidence 4 linked sources Publisher GitHub community Licence [MIT ↗](https://github.com/github/awesome-copilot/blob/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/LICENSE) Revision 7cce7cfb4b61 [Read what was—and wasn’t—checked ↓](#review) “Use when an outage, production incident, or significant service degradation has occurred and the team needs to write a structured blameless post-mortem. …” [GitHub community · upstream description ↗](https://github.com/github/awesome-copilot/blob/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem/SKILL.md) Our analysis follows below. 01 / THE REASONING ## Why this made the selection. - The blameless principle is operational, not aspirational: a common-mistakes table rewrites 'Bob forgot to check the config' into 'the deploy checklist did not include config validation' and treats human error as a symptom, never a root cause. - Action items are held to a hard standard — a named individual owner, a due date, and 'improve monitoring' explicitly rejected in favour of which service, which metric, what threshold, by when. - The full output template (summary, impact table, UTC timeline, root cause, contributing factors, what went well, action items, lessons) is ready to save as a document rather than an outline. ### A good fit for - Writing the postmortem within 48–72 hours of a production incident - Converting a vague 'what went wrong' discussion into a timeline with explicitly flagged gaps - Generating owned, dated, specific action items from a 5-Whys chain - Separate symptom onset from detection-to-resolution duration in an incident impact account. ### Weigh up before choosing - Single self-contained SKILL.md with no references; severity scales and SLA definitions must come from the team's own incident process. - The 5-Whys examples and template assume web-service incidents; other failure classes need adaptation. - Impact quantification depends on data the team supplies; the skill asks for it but cannot verify it. - The sample action table uses team handles, while the surrounding rule requires each action owner to be a person; the template needs an explicit individual assigned. 02 / THE REVIEW RECORD ## What we actually inspected. Source review has boundaries. A clear record is more useful than a “safe” badge. ### Material inspected - skills/incident-postmortem/SKILL.md (complete, 204 lines) - repository LICENSE (MIT) - awesome-copilot skills directory listing - SKILL.md and LICENSE re-read at 7cce7cfb on 2026-10-13 for the downloadable definition; both byte-identical at HEAD 156736fb (git blob SHAs). - skills/incident-postmortem/SKILL.md - vercel-labs/skills@7407f3893ad4dceab546ac002c3ef806e4000c73:README.md - LICENSE ### Our findings - The document defines blameless language up front — 'the system did not', 'the process lacked', 'the alert did not fire' — and enforces it again in the common-mistakes table. - The 5-Whys chain is worked end to end from crash-looping pods to missing load-test fixtures, and stops at a system gap that maps to a concrete action item. - Timeline reconstruction is instructed to check logs, alerts and PagerDuty rather than memory, and to flag unknown intervals explicitly. - The impact step distinguishes detection-to-resolution duration from symptom-start duration. Its action-item rules require named individuals although the illustrative table contains team handles. ### Not established by this review - No postmortem was written from a real incident; the workflow was read, not run. - The output template was not rendered against a team's actual incident record. - Not executed: it was not installed or run. The review applies to the material and revision named here. A newer upstream release can change its behavior. 03 / PUT IT TO WORK ## Add a skill to your workflow. [Upstream setup instructions ↗](https://github.com/vercel-labs/skills/blob/7407f3893ad4dceab546ac002c3ef806e4000c73/README.md) DOCUMENTED COMMAND npx skills add github/awesome-copilot/skills/incident-postmortem --skill incident-postmortem Copy command ↗ Run in your terminal to choose your AI tools, project or global scope, and installation method. This short command follows the current upstream version; the review covers the revision shown above. Optional: install the reviewed revision Keeps the original source and installer version where recorded, while leaving your AI tools and installation scope for you to choose. npx skills add https://github.com/github/awesome-copilot/tree/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem --skill incident-postmortem Copy reviewed-revision command ↗ - Install the skill directory; it is a single self-contained SKILL.md. - Bring the incident details — or let the skill ask for them section by section — and expect a save-ready document plus an owned action-item table. - For manual installation instead, download the complete bundle from https://undominated.ai/resources/skills/github-incident-postmortem/bundle.zip and extract it into a new directory. It holds SKILL.md unchanged at revision 7cce7cfb, the upstream licence and an attribution file. - Place the extracted directory in your host's documented skills directory, named incident-postmortem. Keep SKILL.md and the licence together. ### Before you start - Node.js/npm for the installer - An agent that supports the Agent Skills format - Incident facts: times, severity, affected services, timeline evidence from logs and alerts ### Compatibility Agent Skills-compatible coding agents · Any team with an incident process and a place to publish documents · Framework- and stack-agnostic ### Reads incident notes and logs when supplied; writes the postmortem document - Read incident timelines, logs, alerts and chat evidence the team supplies - Write the postmortem document, typically to docs/postmortems/ - No production access required or requested ### Cost model MIT-licensed instruction package; writing costs only agent time. THE COMPLETE REVIEWED DEFINITION ## Read it before you reuse it. Original source bytes, with attribution. Review the host-specific setup notes above. Copy definition ↗ [Download definition + licence ↗](/resources/skills/github-incident-postmortem/bundle.zip)[Raw Markdown ↗](/resources/skills/github-incident-postmortem/definition.md) --- name: incident-postmortem description: 'Use when an outage, production incident, or significant service degradation has occurred and the team needs to write a structured blameless post-mortem. Triggers on phrases like "write a post-mortem", "incident review", "what went wrong", "outage report", "root cause analysis", or "RCA". Covers timeline reconstruction, contributing factor analysis, impact quantification, and action item generation with owners.' --- # Incident Post-Mortem Guide a team through writing a structured, blameless post-mortem after a production incident. The output is a document that builds shared understanding, identifies root causes without blame, and produces concrete action items to prevent recurrence. ## Blameless Principle Systems fail, not people. The goal is to understand HOW the incident happened — not WHO caused it. Avoid language like "X forgot to", "Y should have known". Use "the system did not", "the process lacked", "the alert did not fire". ## When to Use - Production outage or service degradation has been resolved - A significant near-miss occurred (would have been an incident if caught later) - User-facing errors, data loss, or SLA breach happened - Team wants to capture learnings before context fades **Not for:** Minor bugs caught in staging, planned maintenance windows, or incidents with no learning value. ## Input Requirements Gather these details before writing the post-mortem. Ask for anything missing: ### Incident Metadata - Incident title (short, descriptive) - Date and time of detection (with timezone) - Date and time of resolution - Severity / impact level (P1–P4 or equivalent) - Incident commander / on-call owner ### Impact - Affected services and systems - User-facing impact (errors, slowness, full outage) - Estimated number of users affected - Data loss or corruption (yes/no, scope) - SLA/SLO breach (yes/no, by how much) ### Timeline Events Key moments to reconstruct: - First symptom occurred - Alert fired (or was noticed manually) - On-call paged / incident declared - Investigation started - Root cause identified - Mitigation applied - Full resolution confirmed - Customer communication sent (if any) ### Contributing Factors Ask the team: "What made this worse than it needed to be?" — not "who failed". Examples: - Alert threshold too high / alert didn't fire - Runbook was missing or outdated - Deploy lacked a feature flag for rollback - Monitoring didn't cover this failure mode - On-call handoff missed context ## Process ### Step 1 — Gather Metadata If the user has not provided full incident details, ask for them section by section. Don't proceed to writing until you have: title, times, severity, affected services, and at least a rough timeline. ### Step 2 — Reconstruct Timeline Work with the user to build a precise chronological timeline. For each event: - Exact time (UTC preferred) - What happened (system event or human action) - Who observed it or took the action - Link to log / alert / Slack message if available Flag gaps: "We don't know what happened between 14:32 and 14:47 — worth checking logs." ### Step 3 — Root Cause Analysis Use the **5 Whys** iteratively: ``` Why did users see 500 errors? → The API pods were crash-looping. Why were they crash-looping? → Memory limit was exceeded. Why was the limit exceeded? → A new query was loading full result sets into memory. Why wasn't this caught before deploy? → Load tests only covered the p50 case, not high-cardinality accounts. Why did load tests only cover p50? → We had no test fixtures for large accounts. ``` Stop when you reach a system/process gap you can fix. The last "why" should point to an action item. Distinguish: - **Root cause** — the deepest systemic gap (one or two) - **Contributing factors** — conditions that made it worse but aren't the root cause ### Step 4 — Impact Quantification Help the user be precise: - Duration: detection to resolution (not symptom start to resolution — separate these) - Error rate at peak vs. normal baseline - Percentage of traffic affected - Revenue / business impact if known ### Step 5 — Action Items For each root cause and contributing factor, generate at least one action item: | # | Action | Owner | Due Date | Priority | |---|--------|-------|----------|----------| | 1 | Add load test fixtures for accounts > 10k records | @eng-team | 2026-07-01 | High | | 2 | Lower memory alert threshold from 90% to 75% | @platform | 2026-06-23 | High | | 3 | Add runbook for memory OOM pods | @on-call-rotation | 2026-06-30 | Medium | Action items must have an owner (a person, not a team) and a due date. Vague actions like "improve monitoring" are not acceptable — break them into specific deliverables. ### Step 6 — Write the Document Produce the full post-mortem using the template below. Save to `docs/postmortems/YYYY-MM-DD-.md`. ## Output Template ```markdown # Post-Mortem: [Incident Title] **Date:** YYYY-MM-DD **Severity:** P[1-4] **Duration:** X hours Y minutes (HH:MM UTC – HH:MM UTC) **Incident Commander:** @name **Status:** Resolved --- ## Summary [2–3 sentences. What happened, what was the user impact, how was it resolved. Written for someone who wasn't involved.] ## Impact | Dimension | Value | |-----------|-------| | Affected services | [list] | | User-facing impact | [errors / degraded / full outage] | | Users affected | [estimated number or %] | | Peak error rate | [X% vs Y% baseline] | | Data loss | [none / describe scope] | | SLA breach | [yes/no — by how much] | ## Timeline All times UTC. | Time | Event | |------|-------| | HH:MM | [First symptom / alert fired] | | HH:MM | [On-call paged] | | HH:MM | [Incident declared] | | HH:MM | [Root cause identified] | | HH:MM | [Mitigation applied] | | HH:MM | [Full resolution confirmed] | | HH:MM | [Customer communication sent] | ## Root Cause [1–2 paragraphs. The deepest systemic gap that, if fixed, would have prevented the incident. Written in blameless language. Reference the 5 Whys chain if helpful.] ## Contributing Factors - [Factor 1 — condition that made the incident worse] - [Factor 2] - [Factor 3] ## What Went Well - [Thing that worked — good alert, fast response, clear runbook] - [Another positive] ## What Could Have Gone Better - [Gap in process, tooling, or coverage — no blame language] - [Another gap] ## Action Items | # | Action | Owner | Due Date | Priority | |---|--------|-------|----------|----------| | 1 | [Specific deliverable] | @person | YYYY-MM-DD | High/Medium/Low | | 2 | | | | | ## Lessons Learned [Optional. 2–4 bullet points capturing non-obvious insights worth sharing with the broader team.] ``` ## Common Mistakes | Mistake | Fix | |---------|-----| | "Bob forgot to check the config" | "The deploy checklist did not include config validation" | | Root cause is "human error" | Keep asking Why — human error is always a symptom | | Action items without owners | Every item needs a named individual, not a team | | Timeline reconstructed from memory | Check logs, alerts, Slack, PagerDuty before writing | | "Improve monitoring" as an action | Specify: which service, which metric, what threshold, by when | | Post-mortem written weeks later | Write within 48–72 hours while context is fresh | The download contains SKILL.md . Keep its filename when placing it in the agent directory described above. By **GitHub community**. [Exact upstream source ↗](https://github.com/github/awesome-copilot/blob/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem/SKILL.md) · [Licence](/resources/skills/github-incident-postmortem/LICENSE.txt) · [Attribution](/resources/skills/github-incident-postmortem/ATTRIBUTION.txt) SHA-256 0492b8e05eba16cf045041b519536f906b06b278c77a0a33b4b947ed0b79176b Read the applicable licence MIT License Copyright GitHub, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 04 / FOLLOW THE EVIDENCE ## The source trail. Our notes are separate from the original resource. Check upstream before adopting a new version. - [Skill definition at reviewed revision ↗](https://github.com/github/awesome-copilot/blob/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem/SKILL.md) Checked 2026-10-13 https://github.com/github/awesome-copilot/blob/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem/SKILL.md Supports: summary, upstreamDescription, whySelected, bestFor, limitations, review, access - [Repository licence (MIT) ↗](https://github.com/github/awesome-copilot/blob/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/LICENSE) Checked 2026-10-13 https://github.com/github/awesome-copilot/blob/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/LICENSE Supports: license - [Skills installer source formats and selective installation ↗](https://github.com/vercel-labs/skills/blob/7407f3893ad4dceab546ac002c3ef806e4000c73/README.md) Checked 2026-10-07 https://github.com/vercel-labs/skills/blob/7407f3893ad4dceab546ac002c3ef806e4000c73/README.md Supports: install - [Pinned continuation review W24 ↗](https://raw.githubusercontent.com/github/awesome-copilot/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem/SKILL.md) Checked 2026-10-15 https://raw.githubusercontent.com/github/awesome-copilot/7cce7cfb4b61196c36d7e8eb8475ae84b356b126/skills/incident-postmortem/SKILL.md Supports: review.findings, bestFor, limitations, upstreamDescription KEEP COMPARING ## Other approaches to consider. Related by category or shared topics. These are alternatives to inspect, not a measured quality order. [### Conventional Branch ↗ Creates and validates Git branches against the Conventional Branch specification — feature/, bugfix/, hotfix/, release/, chore/ — with a validation ruleset, an invalid-example table, trunk detection and a mapping to Conventional Commits.](/skills/github-conventional-branch/)[### Conversation to Specification ↗ Turns an already-discussed change into a repository-aware specification for the configured issue tracker.](/skills/mattpocock-to-spec/)[### GitHub Release Workflow ↗ Cuts a library release end to end: tag-derived versioning, code-diff-first SemVer analysis against commit intent, Keep a Changelog authoring, and a gated release-branch plus PR handoff.](/skills/github-github-release/) [AI Tools ↗](/tools/)[Skills ↗](/skills/)[Agents ↗](/agents/)[MCP Servers ↗](/mcp-servers/)[Workflows ↗](/workflows/) ## Continue your investigation - [Choose a toolkit](/tools/) - [Inspect execution hosts](/agents/) - [Check tool access](/mcp-servers/) - [Check project dependencies](/check-repo/)