# Find postmortem actions that slipped past the incident
> Compare postmortem commitments with the issue tracker and code changes, then prepare a reviewed overdue-action report.
Canonical: https://www.mcpfolio.com/workflows/postmortem-action-followthrough
## Target user

SRE or engineering leads responsible for preventing repeat incidents.

## Trigger

Weekly reliability review or a repeat incident points back to an earlier postmortem action.

## Why run it repeatedly

Weekly or before an incident review; actual process cadence varies by team.

## What you receive

A list of actions with source postmortem, matching issue/PR, owner, status, due date, and unresolved verification.

## Pain evidence

A first-person incident discussion describes actions quietly slipping and recurrence. One community thread does not establish prevalence or the value of another dashboard.

## Alternatives and remaining gap

Incident platforms and project trackers can own action items and reminders. A scheduled deterministic report is more reliable; this recipe helps reconcile poorly linked prose records and expose uncertainty.

## Execution flow

1. Retrieve postmortems in the selected period and extract explicitly recorded actions, owners, and dates.
2. Match each action to Linear by linked issue ID first; otherwise report candidate text matches as uncertain.
3. For actions claimed complete by a code change, inspect the referenced GitHub issue/PR/file only if directly linked.
4. Separate overdue, unassigned, completed-but-unverified, and unmatched items.
5. Return a report; do not change issue state or assign work without owner approval.

## Required tools

- Notion: notion-search, notion-fetch
- Linear: list_issues, get_issue
- GitHub: issue_read, get_file_contents

## Prerequisites and costs

Notion access to postmortems; Linear read scope; GitHub access to referenced repositories; consistent links or names for action tracking.

## Run this prompt

```text
Review postmortem actions from [date range]. Match to Linear by explicit issue ID. Use text similarity only to propose candidates, never as a confirmed match. For claimed code completion, inspect directly linked GitHub records. Return overdue, unassigned, unmatched, and completed-but-unverified items with source links. Do not assign, close, or update anything.
```

## Review checkpoints

SRE lead verifies matches, due dates, completion evidence, and whether an action remains relevant. Approval is required before assigning or changing tracker state.

## Limitations

This produces an interactive audit, not persistent reminders. Reliable automation requires scheduled execution and run-state outside MCP. Issue text similarity can mis-link unrelated work.

## Manual work and missing capabilities

External scheduler for recurring checks, stable postmortem-to-issue links, and human validation of whether a closed issue truly resolved the risk.

## Failure handling

Use bounded retries for read failures and mark partial results incomplete. Keep source record IDs and links. Do not guess across missing or conflicting identifiers. Search for an existing target record before any approved write, then retrieve it to verify.

## Pilot acceptance criteria

All sampled postmortem actions are accounted for; exact IDs match correctly; fuzzy matches are labeled candidates; no action is closed or reassigned automatically.

## Product fit

MCPfolio recipe for one-time audit. If teams validate recurring need, package with scheduled execution and duplicate-safe reminders.

## Demo storyboard

Use synthetic postmortems and Linear/GitHub records with one overdue item, one duplicate title, one missing task, and one closed issue lacking a linked change.

## Evidence

Pain reported by users; official tool docs/catalog checked; workflow not runtime tested

## Required MCPs

- [Notion MCP](https://www.mcpfolio.com/servers/notion): Finds postmortem decisions and original action wording.
- [Linear MCP](https://www.mcpfolio.com/servers/linear): Checks owner, status, due date, and linked issue state.
- [GitHub MCP](https://www.mcpfolio.com/servers/github): Verifies referenced pull requests or files when a task claims code completion.

## Official sources

- [Engineers ask what happens to missed postmortem actions](https://www.reddit.com/r/devops/comments/1q30bt7/)
- [Notion MCP docs](https://developers.notion.com/guides/mcp/overview)
- [Linear MCP docs](https://linear.app/docs/mcp)
- [GitHub MCP docs](https://github.com/github/github-mcp-server)


## Related

- [All workflows](https://www.mcpfolio.com/workflows)