🚨 No Trigger Criteria: Why Half Your Incidents Never Get a Postmortem

Overview

Most teams have a postmortem template. Far fewer have a written rule for when a postmortem is required. Without explicit trigger criteria, the decision to write one becomes ad hoc: a loud, customer-visible outage always gets a document, but the quiet three-hour degradation, the near-miss that a lucky retry saved, and the “we restarted it and it went away” incident usually do not. Over time this produces a badly skewed learning record — the organization studies only its most obvious failures and stays blind to the recurring, lower-grade problems that are often the leading indicators of the next big one.

This is a failure mode of the postmortem program, not any single document. Its cost is invisible precisely because the missing postmortems were never written; there is no artifact to point at. But the pattern is measurable: the same class of incident recurs, near-misses go unexamined until they become real outages, and different teams apply wildly different bars for what “counts.” The fix is to make the trigger a rule, not a judgment call made by a tired on-call engineer at the end of a long night.

Symptoms

Missing trigger criteria show up as inconsistency across incidents rather than a flaw in any one postmortem.

• Two incidents of similar severity get very different treatment — one has a full postmortem, the other has nothing.
• Near-misses (“it almost paged,” “the retry saved us”) are never written up.
• The phrase “that one didn’t really need a postmortem” is common and undefined.
• Postmortem volume tracks who was on call, not the actual incident load.
• Recurring low-grade issues have no paper trail, so nobody realizes they recur.
• New team members cannot answer “when do we write a postmortem here?”
• Leadership is surprised by an outage whose smaller precursors were never documented.

Common Root Causes

• No written policy. “When it feels serious” is the de facto rule, which means it varies by person, mood, and workload.
• Severity levels without postmortem mapping. The team has SEV1–SEV4 but never stated which severities require a postmortem.
• Near-misses are out of scope by default. Because nothing broke visibly, there is no trigger, so the most instructive events are systematically skipped.
• Postmortems feel punitive. If writing one is associated with blame, people quietly avoid triggering them for borderline cases.
• The bar is set by effort, not learning value. Teams skip postmortems for “small” incidents because the document is heavyweight, ignoring that a lightweight write-up would be worth it.
• Auto-resolved and self-healing incidents look like non-events. A system that recovered on its own leaves no obvious trigger, even though why it degraded is exactly what you want to know.
• No owner for the postmortem program. With nobody accountable for consistency, criteria never get written or enforced.

Diagnostic Workflow

Assess whether your program has a trigger problem and where it leaks.

1. Ask for the written rule. Request the documented criteria for when a postmortem is required. If it does not exist or is “use judgment,” that is the finding.
2. Reconcile incidents against postmortems. Pull the incident/alert log for a recent quarter and match each to a postmortem. Every unmatched incident is a potential miss — quantify the gap.
3. Look for the near-miss blind spot. Search chat and tickets for “almost,” “got lucky,” “auto-recovered,” and “restarted and it fixed itself.” Count how many produced a write-up. Usually near zero.
4. Test for consistency. Find pairs of similar-severity incidents and check whether they got similar treatment. Divergence means the trigger is a personal judgment, not a rule.
5. Check severity-to-postmortem mapping. Confirm each severity level explicitly states whether a postmortem is required. Gaps here are where incidents slip through.
6. Correlate volume with on-call. If postmortem counts track individuals rather than incident load, the trigger is being applied unevenly.

Example Root Cause Analysis

A platform team was surprised by a full database failover outage that took 90 minutes to resolve. Reviewing the prior quarter revealed something uncomfortable: the same database had entered a degraded, high-replication-lag state four separate times in the preceding two months. Each time it had recovered on its own within 15 minutes, so no postmortem was written — there was no rule that a self-healing degradation warranted one.

The immediate root cause of the outage was replication lag crossing a threshold that triggered an unsafe automatic failover. But the program root cause was the missing trigger criterion: the four precursor events, any one of which would have surfaced the fragile failover logic, never got examined because “it recovered on its own” was treated as a non-event. There was no written rule requiring a lightweight postmortem for recurring auto-recovered degradations or near-misses.

The team’s fix was to define explicit trigger criteria: any SEV1–SEV2, any customer-visible impact regardless of duration, any incident that recurred within 30 days, and any near-miss where a single additional failure would have caused an outage. They paired the criteria with a lightweight template for smaller events so the bar was about learning value, not document effort. Within a quarter, recurring low-grade issues were finally visible as trends instead of vanishing one restart at a time.

Prevention Best Practices

• Write the trigger criteria down. State exactly which conditions require a postmortem so the decision is a lookup, not a judgment call at 2 a.m.
• Map severities to postmortems. For every severity level, declare whether a postmortem is required, and make customer-visible impact a trigger regardless of duration.
• Make near-misses first-class. Explicitly require write-ups for events where one more failure would have caused an outage — these are your cheapest lessons.
• Trigger on recurrence. Require a postmortem when the same class of incident happens more than once in a defined window, even if each instance was small.
• Cover self-healing incidents. Treat “it auto-recovered” as a reason to investigate why it degraded, not a reason to skip.
• Offer a lightweight template. Provide a short-form postmortem so the cost of documenting a small incident is low and the bar can stay inclusive.
• Give the program an owner. Assign someone to enforce the criteria and periodically reconcile incidents against postmortems so misses are caught.

Quick Reference

• Symptom: similar incidents get different treatment → trigger is judgment, not rule.
• Symptom: near-misses and auto-recovered events are never written up → blind spot.
• Symptom: postmortem count tracks on-call person → inconsistent application.
• Fix: write explicit trigger criteria and map them to severity levels.
• Fix: make near-misses and 30-day recurrences mandatory triggers.
• Fix: treat self-healing degradations as investigate-why, not skip.
• Fix: provide a lightweight template and assign a program owner to enforce consistency.

Conclusion

The postmortems you never wrote are the ones you can never learn from, and without explicit trigger criteria those gaps land exactly where they hurt most: on the quiet degradations, the lucky near-misses, and the recurring low-grade issues that precede real outages. Making the trigger a written rule — tied to severity, customer impact, recurrence, and near-miss potential — turns an exhausted late-night judgment call into a simple lookup, and pairing it with a lightweight template keeps the bar inclusive without drowning the team in paperwork. A postmortem program is only as good as its coverage, and coverage starts with deciding, in advance and in writing, what earns a postmortem.