# Give every postmortem action an expiry condition

> Tie incident follow-ups to a risk hypothesis, owner, completion evidence, review date, and explicit close, replacement, or retirement decision.

Canonical URL: https://www.devobs.io/articles/postmortem-actions-that-expire/
By: Ines Costa
Published: 2023-05-12T16:48:06.679Z
Updated: 2026-09-06T08:31:04.426Z
Section: Architecture

A postmortem action should exist only while it reduces a named risk or closes a learning gap. Give it an owner, evidence of completion, and an expiry condition: the date or system change at which the team must verify, replace, or retire it.

Reviewed: 2026-09-06 UTC.

## Classify the intended effect

Write every action as one of four outcomes:

- Risk reduction lowers the probability of recurrence, such as removing a single point of failure.
- Detection shortens time to notice, such as an alert on stuck work rather than CPU.
- Containment limits blast radius, such as per-tenant quotas.
- Learning resolves uncertainty, such as measuring whether retries amplify overload.

This classification prevents vague tasks such as “improve monitoring.” A better action is: “By October 15, page when checkout completion drops below the objective for ten minutes; demonstrate it with a synthetic failure.”

The [Google SRE book’s postmortem chapter](https://sre.google/sre-book/postmortem-culture/) presents postmortems as a way to learn from significant incidents without blame and to identify corrective actions. Learning becomes durable only when the action connects to the failure mechanism.

## Define done as observed evidence

A merged [small pull request in a dependency stack](https://www.devobs.io/articles/small-pull-request-dependency-stacks/) is rarely enough. Detection work is done when an injected symptom produces the expected alert and runbook. Recovery work is done when a restore succeeds within the target. Capacity work is done when a load test shows the new limit and first bottleneck.

Store the evidence link with the action: dashboard snapshot, test run, game-day timeline, decision record, or measured before-and-after behavior. Avoid unsupported claims that a refactor “prevents recurrence.” State the property it enforces and the test that demonstrates it.

Assign one accountable owner, even when several teams contribute. Add a target date based on risk, and define what escalation occurs when the date passes. Ten unranked actions with the same deadline are a promise no one can manage.

## Add an expiry condition

Systems change after an incident. An alert may become redundant, a manual check may be automated, or the affected service may be retired. Permanent promises create noise and obscure current defenses.

Use conditions such as:

- review after three months of production data;
- retire when the old queue is decommissioned;
- replace after the regional failover controller ships;
- close when two witnessed restores meet the objective;
- escalate if the error-budget burn repeats before completion.

The [Google SRE workbook’s postmortem guidance](https://sre.google/workbook/postmortem-culture/) emphasizes that postmortems are effective when they are written well, acted upon, and widely shared, and it provides tools and templates for building the practice. Apply that same discipline to the lifecycle of each action, not only its creation.

Retirement is a decision, not silent abandonment. Record why the risk disappeared, moved, or became acceptable and who agreed. If the risk remains but the action proved ineffective, replace it and preserve the link between them.

## Keep the backlog finite

Review open actions on a fixed cadence with engineering planning. Sort by residual risk and dependency, not incident recency alone. Close duplicates by selecting one canonical action and linking affected incidents. Cap work in progress so teams finish high-value controls before creating many speculative ones.

Separate immediate mitigations from structural work. A temporary rate limit may expire when capacity is added, but its measured effectiveness should inform the permanent design. Track operational toggles and manual checks with shorter review dates because they decay quickly.

Create a small record containing incident, failure mechanism, action class, owner, due date, evidence required, expiry condition, status, replacement, and decision history. The postmortem remains the narrative; the action system becomes the operational ledger.

## Review for behavior change

At expiry, ask whether the action changed detection time, recovery time, recurrence probability, or blast radius. Use incident and exercise data where available. If evidence is missing, schedule a safe exercise rather than extending the item automatically.

Take the oldest ten open postmortem actions. Rewrite each with one risk hypothesis and expiry condition, close those whose systems no longer exist, and select at most three active items based on current residual risk.

## Source references

- <https://sre.google/sre-book/postmortem-culture/>
- <https://sre.google/workbook/postmortem-culture/>