🚨 Postmortem Anti-Pattern: The Box-Ticking Template Postmortem

Overview

The box-ticking postmortem is a document that satisfies the process and teaches nobody anything. Every field in the template is filled: summary, timeline, root cause, impact, action items. Every required meeting was held. The ticket is closed and the compliance dashboard is green. And yet, reading it, you learn nothing you didn’t already know from the incident channel — no insight, no surprise, no understanding of why the system was fragile in the way it was. The template was treated as the goal rather than as scaffolding for thinking, and the thinking never happened.

This anti-pattern is dangerous precisely because it is invisible to metrics. An organization can hit 100% postmortem completion, close every incident within SLA, and still learn absolutely nothing, because the artifacts are hollow. The motions of the process — the fields, the meetings, the sign-offs — get mistaken for the substance of it, which is genuine understanding and durable change. Box-ticking is distinct from a postmortem with vague action items or one that never ships; those at least attempted analysis. This is going through the motions: mechanically populating a form to make the requirement go away, with the analytical engine switched off from the start.

Symptoms

• Root cause restates the summary. “The service went down because the service failed” — a circular non-answer that adds no understanding.
• Every field is filled, none is illuminating. The document is complete and empty at the same time.
• Copy-paste smell. Phrases, action items, or whole sections recycled from previous postmortems with the specifics swapped.
• Generic action items. “Improve monitoring,” “add more testing,” “be more careful” — items that could be pasted into any postmortem for any incident.
• The review meeting is a read-aloud. Someone reads the doc; nobody asks a hard question; it adjourns in ten minutes.
• No surprises, no debate. Nothing in the analysis was learned during the writing; it all just restates what was already known.
• The author’s goal is visibly “get it done.” The doc exists to close the ticket, and it shows.
• Action items with no owner, no date, no follow-through — filler to populate the section, not real commitments.

Common Root Causes

• The template is treated as the deliverable. People believe the job is “fill in the form,” not “understand the incident,” so they optimize for a complete form.
• Postmortems are a compliance requirement. When the review exists to satisfy a policy rather than to learn, authors do the minimum that passes.
• No time is allocated for real analysis. Writing a genuine postmortem takes hours of digging; when only 30 minutes are given, box-ticking is the only thing that fits.
• Nobody reads them critically. If no reviewer ever pushes back on a hollow doc, hollowness becomes the accepted standard.
• Postmortem fatigue. Teams with too many required reviews for minor incidents ration their effort and phone in the rest.
• No feedback loop to outcomes. When action items don’t visibly prevent future incidents, writing them feels pointless, so people stop trying.
• Cargo-culting the format. Teams adopt a big-company template without the culture of inquiry behind it, and end up with the form but not the function.

Diagnostic Workflow

The test for a box-ticking postmortem is not whether the fields are filled — they always are — but whether the document contains understanding that did not exist before it was written. Read the finished doc and ask what a reader learns from it.

The "so what did we learn?" test — for the finished postmortem:
  [ ] Does the root cause explain something NOT obvious from the summary?
  [ ] Is there at least one finding that SURPRISED someone?
  [ ] Could this document be told apart from other postmortems
      if you swapped the service name out? (if NO -> it's generic)
  [ ] Does any action item address THIS incident specifically,
      vs. being paste-able into any postmortem?
  [ ] Did the review meeting produce a question the author
      couldn't immediately answer?
Any "no" -> the motions happened; the analysis didn't.

Then apply the specificity test to the root cause and each action item — the fastest way to catch generic filler:

Take the root cause / action item and ask:
  "Is this specific to THIS incident, or would it be equally true
   of a dozen unrelated ones?"

  "Improve monitoring"            -> generic. Reject.
  "Add a saturation alert on the
   payments queue at depth > 5k,
   which had no alert and backed
   up for 18 min undetected"      -> specific. Keep.

Finally, look at the process around the doc, not just the prose. Was time actually budgeted for analysis? Did the review meeting interrogate or merely narrate? Does anyone track whether action items reduce recurrence? Box-ticking is usually a symptom of a process that rewards completion over comprehension — fix the incentive, not just the individual document.

Example Root Cause Analysis

Incident: A nightly batch job silently failed to run for three days, causing stale data in customer reports.

Box-ticking draft:

Summary:     The batch job did not run for 3 days, causing stale reports.
Root cause:  The batch job failed to execute.
Impact:      Reports were stale.
Action items: 1. Improve monitoring.  2. Add more tests.  3. Be more careful.

Why it’s box-ticking, field by field:

1. Root cause restates the summary. “The job failed to execute” is the thing that happened, not an explanation of why or how it went undetected for three days.
2. Impact is content-free. “Reports were stale” — how many customers, which reports, what decisions were made on bad data? None of the information that would let anyone gauge severity.
3. Action items are generic. All three could be pasted into any postmortem ever written; none references the batch job, the silence, or the three-day detection gap.
4. The interesting question is never asked. The real story is not that a job failed — jobs fail — it’s that it failed silently for three days. That is where the insight lives, and the template glides right past it.

The question that unlocks the real analysis: why did a three-day outage of a scheduled job produce no signal at all?

Substantive rewrite:

Root cause:  The batch job's scheduler marked the run "complete" on a
             non-zero exit, so failures looked like successes. There was
             no freshness check on the output data and no "job hasn't
             succeeded in 24h" alert, so 3 consecutive failures were
             invisible until a customer reported stale numbers.
Impact:      47 enterprise accounts saw reports up to 72h stale; 2 escalated
             billing disputes traced to decisions made on stale figures.
Action items:
  1. [owner/date] Alert when the job has no SUCCESS in >26h (missing entirely).
  2. [owner/date] Add a data-freshness check on report output as a
     backstop independent of job status.
  3. [owner/date] Fix the scheduler's exit-code handling so non-zero != complete.

The difference: the rewrite explains why the failure was invisible (the real fragility), quantifies impact enough to judge severity, and produces action items that are specific to this incident and testable. The box-ticking version closed the ticket; the rewrite would actually prevent the next silent-job outage.

Prevention Best Practices

• Frame the template as scaffolding, not the goal. State explicitly that a complete form with no insight is a failed postmortem, and that understanding — not field-completion — is the deliverable.
• Budget real analysis time. Genuine root cause work takes hours; allocate them, and reserve full postmortems for incidents that warrant the investment.
• Enforce the specificity test. Reject any root cause or action item that would be equally true of a dozen unrelated incidents; require details tied to this one.
• Make review meetings interrogate. The facilitator’s job is to ask “so why did that happen?” until the analysis produces something not already obvious — a read-aloud is not a review.
• Right-size the requirement. Reduce postmortem fatigue by using lightweight reviews for minor incidents and full ones only where there’s something to learn.
• Close the loop to outcomes. Track whether action items actually reduce recurrence, so writing them feels — and is — worthwhile.
• Look for the surprise. A postmortem that taught no one anything new probably skipped the analysis; push it back until it surfaces at least one genuine finding.

Quick Reference

# Box-ticking = filling the template to satisfy process, with no real insight.

The "so what did we learn?" test:
  [ ] root cause explains something NOT in the summary
  [ ] at least one finding surprised someone
  [ ] doc is distinguishable from others (not generic)
  [ ] action items are specific to THIS incident
  [ ] review meeting produced a hard question
  any "no" -> motions happened, analysis didn't

Specificity test (root cause + each action item):
  "specific to THIS incident, or true of a dozen unrelated ones?"
  "improve monitoring"  -> generic, reject
  "alert on payments queue depth >5k (was unmonitored 18m)" -> keep

Process fixes:
- template as scaffolding, not deliverable
- budget hours for real analysis
- review meeting interrogates, not narrates
- track whether action items reduce recurrence

Conclusion

A postmortem is not a form to be completed; it is a thinking process for which the form is merely scaffolding, and when the scaffolding becomes the goal the entire exercise turns hollow. The box-ticking postmortem passes every process check — fields filled, meeting held, ticket closed — while delivering the one thing it was created to prevent: an organization that experiences incidents without learning from them. The remedy is to relentlessly ask “what did we actually learn here?” and to refuse to accept a document that answers “nothing new.” Budget the time, enforce specificity, make reviews interrogate rather than narrate, and connect action items to whether recurrence actually drops. The measure of a postmortem was never whether the template was completed; it is whether the next person, running the same system under the same pressure, is meaningfully less likely to be caught by the same failure.