The postmortem action item ownership decision record: why the accountability model you chose determines whether incident learnings reduce your recurrence rate or accumulate in a stale backlog

A 42-person SaaS company built a contract lifecycle management platform for mid-market legal and procurement teams — contract drafting, approval workflows, and vendor renewal tracking for 310 customers in the enterprise-adjacent market. The engineering organization ran on a two-week sprint cycle with a product backlog that was jointly owned by a product manager and the engineering lead. After incidents, the engineering team conducted a blameless postmortem within 48 hours — a genuine process, not a checkbox exercise — and the incident commander documented action items in the postmortem report at the end of the session. The action items were added to the product backlog at the end of the postmortem report. The product manager reviewed all backlog items at sprint planning and assigned relative priority based on customer impact, roadmap alignment, and engineering effort. Reliability improvements from postmortems competed on these criteria alongside everything else.

In month 11, a database connection pool exhaustion incident caused 47 minutes of API unavailability during business hours — a P1 incident by the company's own severity rubric. The postmortem identified three action items: implement connection pool monitoring with an alert threshold at 80% utilization, add a connection pool size override to the environment configuration rather than hard-coding it, and document the manual connection pool reset procedure in the runbook. At the sprint planning meeting two days later, the product manager reviewed the three items against the current backlog. The connection pool monitoring and the configuration change were reliability improvements with no customer-visible feature value; the runbook documentation had no roadmap tie-in. At the same sprint, the backlog contained a feature requested by the company's two largest enterprise customers: a bulk contract reassignment workflow that the sales team had cited in three deals as a gap relative to competitors. The sprint was committed 95% before considering the postmortem items. The three items were marked medium priority and moved to the next sprint. In the next sprint, a new compliance reporting feature that was required for a renewal was added to the queue and the three items were pushed again. They remained in the backlog for six sprint cycles — 12 weeks — before the second connection pool exhaustion incident occurred in month 14. The second postmortem documented the same three action items plus a fourth. The same sprint planning process applied. At month 19, the third connection pool exhaustion incident occurred. The third postmortem was written by an engineer who was new to the team, who searched the incident history and found the prior two postmortems, and who noted in the document: "All three action items from the month-11 postmortem remain open. One action item from the month-14 postmortem has been completed (the runbook documentation). The remaining three items from the month-14 postmortem remain open." The discovery that the team had documented the same root cause three times and completed one of seven total action items over eight months was not the result of negligence — the product manager and engineering lead had both acted according to their respective optimization targets; the product manager had maximized feature delivery value, and the engineering lead had not pushed back strongly enough on the prioritization outcome to change it. The structural failure was that the decision to allow postmortem action items to compete in the product backlog, with no protected capacity and no separate accountability track, had produced a reliability investment of approximately 5% of available engineering time in a category of incidents that had recurred three times and would continue to recur. Connect this failure pattern to the runbook quality decision record: runbook documentation is the most common category of postmortem action item and the most likely to be completed, because it requires no code changes and can often be done in an hour or two; the completion pattern where runbook updates are completed while architectural or monitoring improvements remain open is a signal that the accountability model for postmortem action items is working for low-effort items and failing for high-effort ones — the structural problem is not effort but competition for engineer time in a prioritization system where the effort required for a reliability improvement works against it rather than in its favor.

A 38-person developer tools company built a CI/CD pipeline intelligence platform — build time trend analysis, flaky test detection, and deployment frequency dashboards for 340 engineering teams at 160 customers. The engineering organization was structured as three functional teams: frontend (5 engineers), backend (8 engineers), and platform (4 engineers). After incidents, the on-call engineer wrote a postmortem within 24 hours and assigned action items to the relevant team. The assignment model was team-based: "platform team: investigate connection broker timeout behavior during high load" or "backend team: add retry logic to the job queue consumer." This assignment model appeared to be meaningful — the relevant team was named, the responsible area was identified, and the action item was visible to all team members in the shared incident tracker. In the first six months of the process, the company had completed 11 postmortems and documented 29 action items.

In month 7, the engineering lead ran the first quarterly reliability review and pulled the completion data from the incident tracker. Of the 29 action items across 11 postmortems, 8 were marked complete and 21 were open. The 8 completed items were a mix — a few had been completed within 2 weeks of the postmortem, several had been completed as a side-effect of other work in the relevant area, and two had been completed because the incident commander had personally followed up with a specific engineer. The 21 open items had two characteristics in common: they were all assigned to teams rather than individuals, and none of the team members for those items had any memory of the specific item being discussed or assigned. When the engineering lead pulled up the incidents that had generated the open items and asked the relevant team members whether they had seen the action item, the answers were consistent: "I thought [name] was handling that," "I figured someone on the platform team had it," "I didn't see that in the backlog last sprint." The action items were not in the team backlogs. They were in the incident tracker, which was a separate system from the work-tracking tool the teams used for sprint planning. The items had been written in the incident tracker at postmortem time and never migrated into the work-tracking system where the teams actually planned their sprints. The team-level assignment had no operational effect because "assign to platform team in the incident tracker" did not produce a ticket in the platform team's Linear queue, the system where all platform work was actually prioritized and assigned. The 38-person company had a functioning incident tracker and a functioning work-tracking system that were operationally disconnected, and the team-level assignment model had no bridge between them. The 16-week-old open items had never been visible to the engineers who were nominally responsible for completing them. In month 9, a second incident recurred from the same root cause as an open action item from month 5 — one of the 21 items that had been team-assigned, never migrated into a sprint queue, and never completed. Connect this failure pattern to the incident response playbook decision record: the incident response playbook specifies the process for conducting the incident response — the roles, the communication protocol, the escalation path — but typically does not specify what happens after the postmortem closes; the ownership model for postmortem action items is almost never specified in the incident response playbook because it requires a decision about how reliability work is prioritized and tracked, which is a different scope than incident response execution; the consequence is that the playbook that governs incident response with high specificity produces postmortems with high quality documentation that feed into an ownership model with no specification, and the action items generated by the best-executed postmortems disappear into the same gap as the action items generated by the worst-executed ones.

A 51-person B2B SaaS built a resource management and capacity planning tool for professional services firms — resource allocation, utilization tracking, and project portfolio analysis for 480 customers in the consulting and agency segment. The engineering organization had invested in incident management after a difficult Q3 the prior year — three P1 incidents in six weeks that had generated two customer churn conversations and a leadership postmortem on the engineering team's reliability practices. The resulting process improvement included individual ownership for all postmortem action items, a 30-day default completion target for medium-priority items and a 7-day target for high-priority items, and a weekly reliability review meeting run by the on-call coordinator to track action item status. The improvement was real: in the six months following the process change, the team completed 67% of action items within their target window, compared to an estimated 20-25% completion rate under the prior unstructured model. The engineering lead viewed this as a significant improvement and considered the postmortem action item tracking process to be working well.

In month 8 after the process change, the team experienced a P2 incident: the resource allocation engine was returning stale utilization data for a subset of accounts when the cache invalidation trigger was not firing on write operations to specific data model paths. The root cause was familiar to the on-call engineer who triaged it — not from personal experience, but from recognizing the pattern during the postmortem: the same cache invalidation gap had been documented as an action item in two prior postmortems, six months apart. The action items from both prior postmortems were marked open in the incident tracker. When the on-call coordinator reviewed the action item history at the reliability review meeting the following week, the pattern became visible: of the 12 action items generated by postmortems in the database and caching tier over the past 8 months, 4 were complete, 8 were open, and the open items were disproportionately concentrated in cache invalidation and query result caching — the exact subcategories that the three P2 incidents had all involved. The 67% overall completion rate masked a 33% completion rate in the caching tier specifically. The engineering team had been completing action items, and the completed items were real reliability improvements in the areas where they were completed. But the 33% completion rate in the caching tier had been invisible in the aggregate metric: 67% overall felt like a success because no one had broken the completion data down by incident category until the third caching incident made the pattern impossible to ignore. The missing feedback loop was the connection between the completion rate metric and the incident recurrence data. The team had both datasets — action item completion status in the incident tracker, incident history by category in the monitoring system — but had not built the query that joined them. The weekly reliability review tracked completion against the 30-day target but did not track which incomplete items corresponded to recurring incident categories, which meant that the reliability review was optimized for completing items on time rather than for completing items in the categories that were generating repeat incidents. Connect this failure pattern to the incident severity classification decision record: the severity classification of a recurring incident — an incident that shares a root cause category with a prior incident whose action items are open — should not be evaluated independently of the prior incident history; a P2 incident with a novel root cause and a P2 incident that recurs from a root cause that had been documented and not fixed carry the same severity classification but very different reliability improvement priority; the completion rate tracking that connects open action item status to incident recurrence frequency is the mechanism that makes this distinction visible before the fourth incident in the same category, not after it.

Structural properties set by the postmortem action item ownership decision

Three structural properties are determined when a team decides — or fails to explicitly decide — where postmortem action items live in the work-prioritization system, who owns each item, and how completion is measured and connected to reliability outcomes: what the backlog placement determines about which action items actually get completed, what the ownership assignment model determines about individual accountability for completion, and what the completion rate measurement determines about the feedback loop between postmortem process quality and incident recurrence. None of these properties are typically analyzed when a team institutes its first incident review process. The backlog placement defaults to the shared product backlog because that is where all work lives; the ownership assignment defaults to the team responsible for the affected area because that is the natural assignment at postmortem time; and the completion rate measurement defaults to a count of completed items without the breakdown by incident category that makes the measurement actionable.

Property 1: The backlog competition surface and the reliability work displacement failure mode. The backlog competition surface is the fraction of postmortem action items whose completion depends on winning sprint planning prioritization against feature work. When all work competes in a single queue, the queue's optimization target determines which work gets done — and a product backlog optimized for feature delivery will consistently displace reliability work that has no customer champion, no revenue correlation, and no roadmap urgency until the incident recurs. The displacement failure mode is not a function of team values or engineering culture; it is a structural output of the prioritization system. A sprint planning process that assigns relative priority based on customer impact and roadmap alignment cannot simultaneously optimize for reliability improvement, because reliability improvements that prevent future incidents have no customer impact until the incident happens and no roadmap position because they were not planned — they were generated reactively by an incident that already occurred. The backlog competition surface can be reduced by two structural changes: a dedicated reliability lane with protected capacity (a specific percentage of sprint hours reserved for reliability work before sprint planning begins, not available for product reallocation) and a separate accountability track for postmortem action items that is reviewed by the engineering lead weekly, independently of the product backlog review. The protected capacity ensures that reliability work is not competing for the same sprint hours as feature work; the separate accountability track ensures that postmortem items are reviewed against a reliability-specific priority framework (recurrence risk, root cause category, completion target) rather than a product-specific one (customer impact, roadmap alignment, revenue correlation). Connect this property to the on-call handoff decision record: the on-call handoff document that accumulates context about recurring alert patterns, known fragile components, and prior-incident background is the primary source of evidence for the reliability review meeting that evaluates postmortem action item priority; action items in categories that the handoff archive identifies as recurring alert patterns should be elevated in the dedicated reliability lane regardless of their backlog position; the engineering lead who uses the handoff archive as input to the reliability review is prioritizing against actual recurrence evidence rather than against the engineer's memory of which areas feel fragile.

Property 2: The individual versus team ownership surface and the diffusion of accountability failure mode. The diffusion of accountability failure mode is the structural consequence of assigning work to a group of people when the work requires action from exactly one. Team-level ownership of a postmortem action item does not produce a single point of accountability — it produces a distribution of assumed accountability across the team, where each team member's assumption about who is the real owner is invisible to the other team members until a deadline passes without completion. The failure mode is not corrected by team culture, commitment, or communication — it is a property of shared ownership structures that is well-documented across organizational contexts and appears consistently regardless of team quality. The individual ownership model does not mean that one engineer completes all the work; a complex reliability improvement may require coordination across multiple engineers and teams. Individual ownership means that one named engineer is accountable for the item's progress — knows the current status, identifies blockers when they arise, escalates to the engineering lead when the completion target is at risk, and updates the status in the reliability review meeting. The accountability is for progress visibility, not for solo execution. The operational requirement that makes individual ownership effective is that the named owner is explicitly confirmed at the time of postmortem — not added as a default later when someone audits the open items — and that the ownership carries a specific completion target date rather than a general priority classification. An action item with an owner and a completion date produces a concrete status question ("is this done by the date you committed to?") that is easy to track and escalate; an action item assigned to a team with a medium priority label produces no concrete status question and no natural escalation path. Connect this property to the runbook quality decision record: runbook update action items, which are the most common category of postmortem action items by volume, are also the category most amenable to individual ownership because the runbook update is a single-author task with a clear completion state — either the runbook contains the procedure or it does not; the completion pattern where runbook updates are consistently completed while systemic reliability improvements remain open is informative about the ownership model's effectiveness for different action item types: individual ownership works for runbook updates even in the absence of a strong accountability structure because the task is self-contained; systemic improvements require individual ownership precisely because they are not self-contained and the coordination required makes diffuse accountability especially costly.

Property 3: The completion rate tracking surface and the reliability investment calibration failure mode. The reliability investment calibration failure mode occurs when a team optimizes for an aggregate completion rate metric without the category-level breakdown that connects completion status to incident recurrence. A 67% completion rate that masks a 33% completion rate in the highest-recurrence category is worse than no metric at all — it produces a false confidence that the postmortem process is working, which delays the investigation into why specific incident categories continue to recur. The tracking surface that makes the calibration visible requires two data connections: the action item status linked to the root cause category of the generating incident, and the root cause category linked to the incident frequency data in the monitoring system. Neither connection requires complex infrastructure — a spreadsheet that maps action item status to incident category provides enough signal for a monthly review to identify which categories have low completion rates and which have high recurrence rates. The connection between the two surfaces the items that should be elevated in the dedicated reliability lane: not the items that are most recently generated, not the items that are most urgent to the engineer who generated them, but the items whose incomplete status correlates with ongoing repeat incidents. The quarterly review that examines completion rate by category and incident recurrence rate by category produces the reliability investment calibration: if the database tier has a 40% action item completion rate and a 3× recurrence rate relative to other tiers, the reliability lane should be allocating more capacity to the database tier until the completion rate improves and the recurrence rate responds. Connect this property to the incident severity classification decision record: the severity classification of an incident is a component of the action item priority rubric — a high-severity action item (generated by a P1 or P2 incident) should receive a shorter completion target and higher reliability lane priority than a medium-severity action item; but the severity classification of the generating incident is only one input to the action item priority; the recurrence frequency of the root cause category is the second input, and it is the one that the completion rate tracking surface supplies; an action item that was generated by a P3 incident but whose root cause category has a 4× recurrence rate over the past 90 days should be treated as higher reliability lane priority than an action item generated by a single P1 with no recurrence history, because the probability of future value from completing the P3 item is higher; the action item priority rubric must incorporate both the incident severity and the recurrence frequency to produce a calibrated priority order rather than one that over-weights recent high-severity incidents at the expense of chronic low-severity recurrences.

The postmortem action item ownership ADR: five sections

Section 1: Action item priority classification at postmortem time. Begin the postmortem action item ownership decision record by specifying the classification rubric that assigns each action item a priority tier and a default completion target at the point of postmortem — not retrospectively during a backlog grooming session. The rubric must specify classification criteria that can be applied by the incident commander at the end of the postmortem review meeting, without requiring additional research or external input. A three-tier classification: High (7-day target) — the action item prevents a root cause category that the postmortem classified as generating a P1 or P2 incident, or the root cause is producing active customer impact at a lower rate than the triggering incident (for example, a cache invalidation bug that caused a P2 incident during peak traffic but is producing intermittent P3-level impact outside peak windows); Medium (30-day target) — the action item improves a known fragile component, adds monitoring or alerting for a gap identified during the incident, or documents a procedure that was improvised during the incident response; Low (90-day target) — the action item is a quality improvement, a code cleanup related to the incident area, or a documentation update that reduces onboarding friction rather than incident risk. The classification must also specify the escalation trigger: when an action item reaches its target completion date without being completed, the owner must provide an explanation and a revised completion date at the next reliability review meeting, and a high-classification item that is not completed within 7 days requires automatic escalation to the engineering manager for resource commitment. Without an escalation trigger, the completion target is aspirational — an item that misses its target date with no consequence produces the same outcome as an item with no target date at all. Connect this section to the incident severity classification decision record: the incident severity rubric must be referenced in the action item classification rubric — the mapping from incident severity to action item priority tier must be explicit, not inferred; a postmortem for a P1 incident should produce action items that are classified as High unless the incident commander can document a specific reason why the root cause does not meet the High classification criteria; a postmortem that consistently produces Medium or Low classifications for P1 incidents is a signal that the incident classification is being used to lower the pressure on the action item completion process, not a signal that P1 incidents are generating only medium-priority reliability improvements.

Section 2: The individual ownership assignment model. Specify the ownership assignment model that governs how each action item acquires a named individual owner at the time of postmortem. The model must specify: who is the appropriate owner for each action item category (the engineer most familiar with the relevant system component, not the incident commander by default), how ownership is confirmed during the postmortem meeting (a specific step at the end of the postmortem review where each action item is reviewed, an owner is proposed, and the proposed owner either accepts or proposes an alternative), and what the owner's responsibilities are between postmortem and completion review (status update before each weekly reliability review meeting, blocker escalation within 48 hours of identifying a completion risk, revised completion date estimate when the original target is at risk). The ownership assignment must also specify the action item migration path: the item must be moved from the incident tracker into the work-tracking system where the named owner's team plans and executes sprint work — typically a Linear ticket, a Jira issue, or a GitHub project card — within 24 hours of the postmortem closing, and the work-tracking ticket must reference the postmortem document and the incident ID. Without the migration step, the action item exists in the incident tracker but is invisible to the team's sprint planning process, which means it competes for no capacity and produces no ownership experience for the named owner until the next reliability review surfaces it as overdue. The migration step is the bridge between the postmortem process and the sprint execution process; without it, the ownership assignment and the completion target exist as documentation artifacts with no operational effect. Connect this section to the incident response playbook decision record: the incident response playbook should specify the postmortem closing procedure as an explicit step — the same level of specificity that the playbook applies to incident detection, escalation, and communication should be applied to the postmortem closing; the closing procedure specifies: all action items have been classified, all action items have a named owner who has confirmed the assignment, all action items have been migrated to the work-tracking system with a reference to the postmortem document, and the completion targets have been entered in the reliability review tracking sheet; the incident is not closed until the closing procedure is complete; this makes the ownership assignment a required output of the incident process rather than an optional step that the incident commander may or may not complete before moving on to the next sprint.

Section 3: The dedicated reliability accountability track. Specify the accountability track that governs postmortem action items separately from the product backlog. The accountability track requires three specifications: the tracking system where action items live after migration from the incident tracker (a dedicated Linear team, a separate Jira project, a GitHub project with a reliability-specific workflow — the specific tool matters less than the separation from the product backlog and the weekly review cadence); the protected capacity allocation that the engineering team commits to reliability work before sprint planning (a specific percentage of sprint hours — a common starting point is 10 to 15% of total engineering capacity, adjusted based on reliability SLO performance and incident frequency); and the review cadence and format for the weekly reliability review meeting (duration: 30 minutes maximum; agenda: open action items sorted by days-to-target-date, new action items from the past week's postmortems, items that have missed target date requiring explanation, and the weekly reliability metric summary; attendees: on-call coordinator, engineering lead, and the named owners of items with target dates in the next 14 days). The protected capacity allocation is the mechanism that prevents the displacement failure mode: reliability work competes against other reliability work for the allocated capacity, not against feature work for shared capacity. The engineering team's total sprint capacity is divided before sprint planning begins: the reliability allocation is filled by the reliability accountability track, and the remaining capacity is available for product backlog prioritization. Product managers can see the reliability allocation and understand that the protected hours are not available for feature work, but cannot reallocate them. The reliability allocation can be adjusted quarterly — if the incident frequency is declining and action item completion rates are high, the allocation can be reduced; if incident frequency is increasing or completion rates are below target, the allocation must increase. Connect this section to the on-call handoff decision record: the on-call handoff archive is the input dataset for the weekly reliability review meeting; the on-call coordinator who runs the reliability review should review the prior week's handoff documents before the meeting to identify new alert patterns, recurring quiet-shift anomalies, and system behavior changes that were documented by on-call engineers but not yet associated with a formal postmortem; these handoff observations are candidates for new reliability action items that precede the incident — if the on-call archive shows that a specific alert has been silenced on sight three times in the past two weeks, the reliability review should generate an action item to investigate the root cause before it produces a fourth incident, not after.

Section 4: Completion rate measurement and the category-level feedback loop. Specify the completion rate measurement model that provides the feedback loop between action item status and incident recurrence. The measurement must operate at two levels: the overall completion rate (the fraction of action items completed within target window across all categories, reviewed monthly) and the category-level completion rate (the fraction of action items completed within target window for each root cause category, reviewed quarterly). The category-level measurement requires a classification schema for root cause categories that is applied consistently across all postmortems — database tier, caching layer, authentication and authorization, deployment pipeline, external dependency failures, data model changes. The same category schema must be applied to the incident frequency data in the monitoring system so that the comparison between category-level completion rate and category-level incident recurrence rate can be computed from two aligned datasets. The quarterly review examines the correlation: categories where completion rate is below the overall average and incident recurrence rate is above the overall average are the categories where the reliability lane is not allocating sufficient capacity, where the ownership model may be producing diffusion for items in that category (common when the category spans multiple team ownership boundaries), or where the action items are under-classified (items in a high-recurrence category may be consistently classified as Medium or Low, which produces a lower completion urgency than the recurrence evidence justifies). The quarterly review produces a calibration recommendation for the following quarter: specific categories where the reliability lane allocation should increase, specific action items that should be reclassified upward, and specific ownership patterns that should be changed from team-level to individual-level. The review should also produce a staleness audit: any open action item older than 90 days for a Medium classification or older than 180 days for a Low classification requires either a committed completion date with engineering manager sign-off or a formal close-as-no-longer-necessary with documented reasoning. The staleness audit prevents the open item list from accumulating items that no one intends to complete, which degrades the signal value of the completion rate metric by including items that were implicitly abandoned. Connect this section to the incident severity classification decision record: the category-level completion rate review is the mechanism for identifying whether the severity classification rubric is producing action item priorities that are calibrated to actual recurrence risk; a category that has both low completion rates and high recurrence rates is a category where the action items may be under-classified — the incident severity rubric may be classifying incidents in that category as P3 when their recurrence frequency and customer impact pattern justify P2; the quarterly review of completion rate by category should include a review of severity classifications for incidents in each high-recurrence category to confirm that the severity rubric is producing priority signals that are consistent with the recurrence evidence.

Section 5: The staleness protocol and the action item lifecycle governance. Specify the staleness protocol that governs what happens when an action item reaches its target completion date without being completed, when an action item becomes superseded by other work, and when an action item should be formally closed as no-longer-necessary rather than left open indefinitely. The staleness protocol has three trigger states. First, target date missed: the item's named owner must provide an explanation at the next reliability review meeting — not a deferred explanation via async comment, but a live explanation in the meeting — and must commit to a specific revised completion date. A High-classification item that misses its 7-day target requires automatic escalation to the engineering manager within 24 hours; a Medium-classification item that misses its 30-day target produces an engineering lead review at the next reliability meeting; a Low-classification item that misses its 90-day target is reviewed monthly and can be deferred once with owner explanation before requiring engineering manager review. Second, superseded by other work: an action item is superseded when other engineering work addresses the root cause more comprehensively than the action item specified — for example, if a postmortem action item specified "add monitoring for cache invalidation failures" and a subsequent architectural decision replaced the caching implementation entirely, the monitoring action item is superseded; the named owner must document the superseding work and the reason the action item is no longer necessary, and the item is closed with status "superseded" rather than "completed"; the supersession record is included in the completion rate calculation as a distinct category rather than as a completion or an abandonment. Third, close-as-no-longer-necessary: an action item may become irrelevant due to changes in system architecture, customer base, or product direction; the engineering lead must approve any close-as-no-longer-necessary decision for High or Medium items, and the decision must include a documented assessment of whether the root cause addressed by the action item is still present in the system and, if present, why addressing it is no longer a priority. An action item that is closed as no-longer-necessary without documenting whether the root cause still exists is an information loss event — future postmortems may re-discover the same root cause and re-open essentially the same item, repeating the cycle that the staleness protocol was designed to prevent. Connect this section to the runbook quality decision record: runbook update action items that reach the staleness protocol are a specific category requiring additional scrutiny — a runbook update that has been open for 90 days without completion is a signal that the runbook's maintenance model is not producing timely updates; the runbook quality decision record specifies the update cadence and ownership model for runbooks; if the postmortem process is consistently generating runbook update action items that accumulate in the staleness protocol, the root cause is not the action item ownership model but the runbook maintenance model, and the fix is to update the runbook quality decision record to include postmortem-triggered updates as a mandatory maintenance trigger rather than leaving runbook updates as a category of reliability work that competes in the standard action item ownership process.

FAQ

Further reading

• Runbook quality decision record — runbook updates are the most common category of postmortem action items and the most likely to be completed on schedule because they are single-author, clearly-bounded tasks; when runbook updates are consistently completed while architectural and monitoring improvements remain open, the pattern reveals a structural asymmetry in the ownership model: individual ownership works well for self-contained tasks but the coordination burden of systemic improvements makes diffuse accountability especially costly; the runbook quality decision record specifies the maintenance model that governs how runbooks are updated after incidents, including whether postmortem-triggered updates are mandatory — if they are not mandatory, the postmortem process generates runbook update action items that compete in the standard ownership process rather than being executed as part of the incident closure procedure, and the mandatory-update model eliminates an entire category of action items from the reliability lane by treating runbook updates as a required incident closure step rather than as optional follow-up work.
• Incident response playbook decision record — the incident response playbook specifies the execution model for incident handling with high specificity but almost never specifies what happens after the postmortem closes; the postmortem closing procedure — action item classification, named owner confirmation, work-tracking system migration — should be an explicit step in the incident response playbook at the same level of specificity as incident detection and escalation; making the closing procedure a required playbook step transforms the ownership assignment from a post-incident best-effort activity to a required incident closure gate, which is the structural change that produces consistent action item migration rates rather than migration rates that depend on the incident commander's individual thoroughness; the playbook should also specify the handoff from incident commander (who drives the postmortem) to the named action item owners (who drive the completion process), so that the incident commander's responsibility is clearly bounded and the named owners' responsibilities begin at a defined handoff point.
• On-call handoff decision record — the on-call handoff archive is the primary source of evidence for the weekly reliability review meeting that governs postmortem action item priority; the handoff document's quiet-shift anomaly section captures recurring alert patterns, alert-silenced-on-sight behaviors, and fragile component observations that accumulate in the on-call archive before they produce a formal incident; the reliability review that uses the handoff archive to identify pre-incident signals can generate action items proactively — before the fourth occurrence of a pattern produces a postmortem that documents the same root cause for the third time; the on-call coordinator who runs the reliability review should review the prior week's handoff documents before each meeting and flag any recurring patterns as candidate reliability lane items; connecting the handoff archive to the action item ownership process makes the reliability investment proactive rather than purely reactive, which is the structural property that allows the postmortem action item process to reduce recurrence rate rather than only respond to it.
• Incident severity classification decision record — the incident severity classification is the primary input to the action item priority rubric, which means that a systematic error in the severity classification propagates into an error in the action item priority that is invisible until the completion rate measurement reveals the discrepancy; if the severity rubric consistently classifies incidents in a high-recurrence category as P3 when their customer impact and recurrence frequency would justify P2, the action items generated by those incidents are consistently classified as Medium rather than High, receive 30-day rather than 7-day targets, and are completed at the lower urgency level while the category continues to generate repeat incidents; the category-level completion rate review is the mechanism for surfacing this type of systematic misclassification, because the combination of low completion rate and high recurrence rate in the same category is the signature of action items that are under-classified relative to their actual recurrence risk; the fix requires updating the severity rubric to incorporate recurrence history as an explicit input, not only instantaneous customer impact.
• Open-source extractor — find the postmortem action item ownership decisions buried in your AI chat history: the incident review session where the engineering lead discussed whether to put reliability action items in the product backlog and decided "for now" that a separate track was too much process overhead for a team of 12 — a decision that becomes the de facto ownership model when the team is 40; the postmortem session where the incident commander assigned three action items to "the platform team" and someone said "we should probably make sure someone actually owns these" and everyone agreed and then the meeting ended; the quarterly retrospective where the team discussed that the same database incident had recurred twice and someone said "didn't we already have an action item for this?" — the answer was yes, it was in the incident tracker, it had been open for eight weeks, and no one had migrated it to Linear; and the engineering all-hands where the engineering lead discussed the completion rate metric showing 67% on-time completion and the team felt good about the number without anyone asking which categories were in the 33%; these are the sessions where the postmortem ownership model was formed or reinforced, and recovering them from your AI chat history makes the next ownership process a deliberate set of decisions rather than an accumulation of default behaviors from meetings where the important part happened in the last three minutes before everyone left.