Blameless Postmortem

Turn incident notes into a blameless postmortem: timestamped timeline, systemic contributing factors, and action items with owners.

Write a blameless postmortem from my raw incident material.

Raw material (Slack threads, alerts, PR links, notes: messy is fine):
"""
[PASTE EVERYTHING: when things fired, who did what, what was tried, what worked]
"""
Impact facts: [DURATION / USERS OR CUSTOMERS AFFECTED / REVENUE OR SLA IMPACT / DATA LOSS Y/N: what's known]
The system: [WHAT BROKE, IN ONE LINE + the stack around it]

Structure:
1. **Summary**: 3-4 sentences: what happened, impact, duration, root-level cause. Written for someone who wasn't there and won't read further.
2. **Impact**: the concrete numbers from my facts. Where a number is unknown, write "unquantified: [how to get it]" rather than an estimate dressed as fact.
3. **Timeline**: timestamped, from first trigger through detection → diagnosis → mitigation → resolution. Facts only, no interpretation. Compute and highlight the two metrics that matter: time-to-detect and time-to-mitigate. Flag timeline gaps where my material goes quiet: [GAP: what happened between X and Y?].
4. **Contributing factors (2-5, systemic)**: this is where blameless is enforced: every human action gets reframed as the condition that made it possible. "Engineer ran the migration on prod" becomes "prod and staging credentials were interchangeable in the tooling; nothing distinguished the two environments at the point of action". Ask "why was this possible?" up the chain (5-whys style) until you hit process, tooling, or design, never stop at a person. If my material names-and-blames, rewrite it and note the reframe.
5. **What went well**: detection, escalation, or design choices that limited the blast radius. Real ones only; ritual positivity dilutes the document.
6. **Action items**: table: action | type (prevent recurrence / detect faster / reduce blast radius) | owner role | due date. Each action must trace to a contributing factor. Reject vanity actions ("be more careful", "add more tests" without which tests): every action must be checkable as done/not-done. Mark the ONE action that most reduces recurrence risk.
7. **Lessons**: 2-3 transferable lessons for teams that don't run this system.

Rules: strictly from my material, no invented timestamps, no assumed causes; where cause is uncertain, say "suspected, pending [verification]". The test of blamelessness: every person in this document could read it in the room and nod.

How to use

The blameless reframe in step 4 is the whole discipline: the Google SRE practice exists because named-and-shamed engineers stop reporting near-misses, and the systems never improve. Write the postmortem within 48 hours while the Slack threads still make sense. Track the action items in your issue tracker with real owners; a postmortem whose actions die in the doc is theater.

Originated fromStan SedberryUpdated
Documentationintermediate

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner
Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate
Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.

Codingintermediate

Search prompts

Find a prompt by title, description, tag, or category.