Postmortem action items that actually close.

01 · The problem

The postmortem is the part you're good at.

You find the root cause, write the remediations, assign owners in the room. Then the incident stops hurting — and the alert that would have caught it next time sits in a doc, un-ticketed, un-owned past the meeting. The next outage doesn't need a new root cause. It reuses the old one.

2 of 5actions never became a ticket at all line 3where the reason for the next outage was written

02 · What you need

Nothing lands in Jira until you sign off.

Each action becomes a tracked ticket with a named owner and a stop-waiting date — a person, not a team. She drafts it with the incident's context attached, checks it isn't already filed, and hands it to you to preview, edit or refuse. After that, the chasing is hers.

0tickets filed before you approved them contextthe incident travels with the ticket, not just its title

03 · How it runs

A blameless postmortem deserves a blameless chase.

Set where the asking happens and what a "done" gets checked against. Every step rewrites itself to match — she checks in once with a quiet owner, and if an item is still stalled past its date she escalates with the item's history attached, not with blame.

04 · What it's worth

“Done” means the ticket moved.

A remediation isn't closed because an owner typed "shipped" in a thread. She does not detect, triage or run your incident — your on-call stack owns the outage while it's live, and it should. Her job starts when the postmortem is signed and the room empties.

1 of 2claims here didn't survive the check not liveshe doesn't run incident response — only the follow-through