A postmortem action can be complete in the issue tracker while the failure it was supposed to address remains entirely possible. Someone added an alert, updated a runbook, or merged a configuration change. The ticket has a link to the work. Nobody has checked whether that work changes the outcome.

That gap deserves attention because the closed ticket looks reassuring. It can appear in an incident review, a reliability roadmap, and a quarterly progress report without ever encountering the condition it was meant to handle.

Treat each important postmortem action as a claim about future system behavior. Write down what would make the claim credible, gather that evidence safely, and decide when to check whether the improvement still holds. You can do this in the existing ticket. Another tracking system is rarely the missing piece.

Start with the failure mode you intend to change

“Improve monitoring” describes a direction. “Detect stalled reconciliation before the pending queue exceeds its recovery window” names a behavior the team can examine.

The distinction matters when several changes could satisfy the original wording. A new dashboard might improve visibility while leaving the on-call responder unaware of a growing backlog. An alert might fire reliably but route to an unstaffed destination. Both changes can be real work without solving the operational problem.

Link the action to the relevant incident evidence. State the observed gap, the affected path, and the consequence you want to reduce. Keep hindsight separate from what responders knew at the time. The incident-timeline guide explains how to preserve that distinction during the response.

Avoid promising that one change will prevent every recurrence. An action might reduce detection delay, bound a failure's impact, or make recovery less error-prone. Those are useful improvements even when they do not eliminate the initiating failure.

Give the action an owner and an observable end state

Google's postmortem guidance calls for action ownership, tracking, prioritization, and verifiable end states. Build on that foundation by making the evidence explicit before implementation begins.

Use one accountable owner who can coordinate collaborators and report the result. That person does not have to write every line of code or approve their own change. They do need to know what remains unresolved, including validation that another team must perform.

Here are fictional examples of how an action can become testable:

The table is a pattern, not a universal set of thresholds. Choose an acceptance criterion tied to your own system's failure mode and operating constraints. A precisely measured irrelevant metric is still irrelevant.

Separate implementation evidence from behavior evidence

A merged pull request proves that an implementation changed. A deployment record shows that a version reached an environment. Neither establishes that the intended operational path works end to end.

For an alert, distinguish at least these questions:

• Does the condition evaluate as expected for the affected population?
• Does the notification reach the correct staffed destination?
• Can the responder identify the impact and take an authorized next step?
• Does the signal clear or change appropriately when the condition ends?

A test notification can validate routing without validating the query. A query test can validate matching without exercising escalation. Record which layer each piece of evidence covers instead of treating one green result as proof of the whole chain.

Some actions primarily change a human workflow. For a handoff improvement, examine whether the receiving responder can identify the current impact, restrictions, and accepted ownership. A completed template is only an input. The incident-handoff article provides the operational questions that make that test useful.

Choose the smallest credible verification

You do not need to recreate the original outage to learn whether an improvement works. Often that would create unnecessary risk and introduce enough unrelated behavior to make the result harder to interpret.

Use an isolated test, fixture, replay with protected data, or rehearsal when it can exercise the relevant behavior. Identify what differs from production: permissions, traffic shape, dependency behavior, notification configuration, or available capacity. Those differences determine how much confidence the result deserves.

For example, a staging alert delivered to a test inbox shows something useful, but it does not establish production paging ownership. Combine it with a separately authorized routing check if that is the unresolved part. Do not silently turn a postmortem ticket into permission to page people or alter production load.

For any verification with operational consequences, agree on scope, authorization, rollback or stop conditions, and who observes the result. If a safe test cannot cover the important path, state the limitation and choose an additional review or later observation. “Not yet demonstrated” is a valid finding.

Put the verification plan in the ticket

A short record is enough when it answers the questions that future reviewers will otherwise have to reconstruct. This fictional template can sit beneath an ordinary action description:

Observed gap:
  Stalled reconciliation was visible
  only after customer reports.
Intended behavior:
  A sustained stall reaches the owner
  before the agreed recovery window
  is exhausted, with time to investigate.
Accountable owner:
  Reconciliation service owner;
  named assignee in this issue.
Acceptance:
  Controlled stall fixture matches.
  Authorized routing check reaches
  the intended destination.
  Receiving responder can locate
  the affected queue.
Evidence:
  Test version, environment, timestamps,
  results, and durable links.
Limits:
  Fixture does not model every
  production traffic pattern.
Follow-up:
  Review after the next relevant event
  or routing change. Schedule a bounded
  check if neither occurs within
  the agreed interval.
Outcome:
  Implemented / verified within stated
  limits / further work required.

Keep evidence accessible to the people responsible for the service. A dashboard link with a relative time range will eventually show a different period. A build artifact that expires next week will not support a review next quarter. Preserve the relevant version, absolute time window, and a durable result under your retention rules.

Do not paste credentials, customer payloads, or sensitive incident material into a broadly visible ticket. Link to the appropriate protected evidence and describe its significance without duplicating unnecessary data.

Check effectiveness after acceptance

Acceptance answers whether the change meets its declared criteria under the checked conditions. Effectiveness asks whether it continues to help in operation.

Agree on a follow-up trigger while the action is fresh. Useful triggers include the next relevant deployment, a dependency or permission change, an operational exercise, or an incident involving the same path. Add a time-bounded review when an event alone could leave the action unchecked indefinitely.

Absence of another incident is weak evidence by itself. The triggering condition may simply not have happened. Conversely, a recurrence does not automatically mean the action failed: a detection improvement might have shortened the response while leaving the underlying trigger possible.

Compare the observed behavior with the specific intended improvement. Did the notification arrive? Did the runbook support the responder's decision? Did the concurrency limit protect the downstream service while exposing a new backlog tradeoff? Record the answer and its uncertainty.

Make failed verification useful

If a check fails, preserve the result and update the work. Reopen the action or create a linked follow-up according to the team's normal workflow. Do not rewrite the original acceptance criterion merely to make the ticket look complete.

Sometimes the original action was the wrong investment. A rehearsal may show that another dependency dominates recovery time, or that an alert duplicates an existing signal without improving response. Explicitly replace or retire the action with a rationale. Keeping a weak action alive forever is not accountability.

Prioritize verification by consequence and uncertainty. A production recovery safeguard deserves more evidence than a corrected internal link. Avoid measuring success by the number of closed actions; that rewards decomposition and easy fixes rather than reduced operational risk.

Close the loop with a claim you can defend

Before closing an important postmortem action, ask what changed, what evidence demonstrates the intended behavior, what remains untested, and when the team will look again.

Those answers make a closed ticket useful. They let the next responder understand why a safeguard exists and let the next reviewer distinguish an implemented idea from an operational improvement. The goal is a system that behaves better when the relevant condition returns, with enough evidence to explain that confidence.

Find more practical engineering and operations guidance at Slaptijack.