Incident Action Items Tracker
Turn incident action rows into due-state and owner follow-up views with blocker, missing-detail, stale-overdue and workload checks.{{ summaryTitle }}
{{ summaryLine }}
{{ summaryAnnouncement }}
| Incident | Action | Owner | Priority | Due | State | Follow-up | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.incident }} | {{ row.action }} | {{ row.owner }} | {{ row.priority_label }} | {{ row.due_display }} | {{ row.state_label }} | {{ row.follow_up }} |
- {{ message }}
| Owner | Open | Overdue | Blocked | Due soon | Next due | Meeting nudge | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.owner }} | {{ row.open }} | {{ row.overdue }} | {{ row.blocked }} | {{ row.due_soon }} | {{ row.next_due }} | {{ row.nudge }} |
The chart renderer is unavailable. Owner counts remain available in the follow-up table.
Incident follow-up turns lessons from an outage or security event into owned work. A useful action says what must change, names one accountable owner, sets a reviewable due date, and points to the ticket or evidence that will prove completion. Without those fields, a post-incident list can look busy while risk remains unchanged.
Due dates make the list time-sensitive, but they do not show importance by themselves. A late documentation task and a blocked critical control may need very different attention. Priority, status, owner, and closure evidence must be read with the calendar state rather than reduced to one total.
- Due soon
- An open action due on the reference date or within the selected future window.
- Overdue
- An open action whose due date is before the reference date.
- Stale overdue
- An overdue action whose age reaches the selected escalation threshold.
- Closure evidence
- A concrete record that the agreed remediation was completed and checked, not only a closed status.
The reference date is the review's clock. Moving it can change the same action from open to due soon, overdue, or stale overdue. Teams should use the meeting or handoff date consistently when comparing snapshots across weeks.
Owner counts reveal concentration, not effort or risk. One complex blocked remediation may matter more than several small open tasks. The ledger remains a review aid; the ticketing or incident system stays authoritative for scope, changes, acceptance, and evidence.
How to Use This Tool:
Prepare delimited action rows, then set the calendar boundaries used for the review.
- Paste rows into Action rows or load one CSV, TSV, or TXT file up to 2 MB. A header is safest when different teams use different column orders.
- Keep Source format on auto when the first nonblank row clearly uses commas, tabs, pipes, or semicolons. Pin the format if quoted text or mixed separators make the choice ambiguous.
- Set Reference date to the review date, choose a 1-to-14-day Due-soon window, and choose a 3-to-30-day Stale-overdue threshold.
- Read Action Ledger from the top. Correct missing action, owner, or due-date fields before relying on follow-up text, then use Owner Follow-Up to prepare the next conversation.
- Use Owner Load Chart to spot concentrations, then return to the ledger before reassigning or escalating work. Counts alone do not measure severity or effort.
Interpreting Results:
The ledger sorts urgent review conditions ahead of ordinary open work. Within the same state, critical priority comes before high, medium, low, and unset priority; earlier due dates then come first.
- Missing info means the action, owner, or valid due date is absent. Fix the source before depending on reminders or owner counts.
- Blocked takes precedence over stale, overdue, and due-soon display states, although its due date still contributes to owner totals.
- A closed row without evidence creates a warning. Closure still needs verification in the authoritative incident record.
- The owner order is a meeting-priority heuristic. It intentionally gives extra weight to overdue, blocked, due-soon, and missing-detail work while also counting every open action.
Technical Details:
The action source is parsed into rows, header names are mapped to canonical fields, familiar status and priority words are normalized, and each due date is compared with one explicit reference date. The same normalized rows feed the ledger, owner follow-up, warnings, and chart.
Transformation Core
| Stage | Transformation |
|---|---|
| Format | Auto detection counts separators outside quoted cells on the first nonblank row; CSV wins a tie because it is checked first. |
| Header | A header is accepted when at least two known field aliases are found and one maps to action, owner, or due date. |
| Headerless rows | Read in this order: action, owner, due date, status, priority, incident, tracker, evidence. |
| Status | Words such as done or resolved become done; blocked or waiting become blocked; working becomes in progress; deferred or cancelled become deferred; other text becomes open. |
| Priority | P0 and urgent terms become critical, P1 becomes high, P2 becomes medium, P3 or P4 becomes low, and unmatched text becomes unset. |
The text source is limited to 200,000 characters and 500 action rows. Dates must be real Gregorian calendar dates in YYYY-MM-DD form. Blank incident cells use Default incident when supplied, otherwise “Incident review.”
Formula Core
Calendar difference is calculated in whole days from the reference date. Because both inputs are calendar-day numbers, daylight-saving clock changes do not create fractional-day results.
A negative d is overdue, zero is due today, and a positive value is the number of days left.
Owners are ordered by a repository-authored pressure score. The score ranks review attention; it is not an estimate of hours, severity, or business impact.
Here, O is overdue count, B is blocked count, S is due-soon count, N is every non-closed action, and M is missing-detail count. Categories can overlap in the score: for example, a blocked action due today contributes to blocked, due-soon, and open counts.
Rule Core
Each row receives the first matching display state in this order.
| Order | Condition | State |
|---|---|---|
| 1 | Normalized status is done | Closed |
| 2 | Action, owner, or valid due date is missing | Missing info |
| 3 | Normalized status is blocked | Blocked |
| 4 | d < 0 and |d| ≥ stale-overdue threshold | Stale overdue |
| 5 | d < 0 | Overdue |
| 6 | 0 ≤ d ≤ due-soon window | Due soon |
| 7 | No earlier condition matches | Open |
Rows are sorted by state order, priority order, due date, and action text. Owner rows are sorted by descending pressure score and then owner name. Warnings are deduplicated and limited to the first eight messages.
Privacy Notes:
Incident rows may contain service names, customer impact, ticket IDs, evidence links, and remediation details. Pasted text and selected files are parsed in the browser and are not sent to a separate action-processing service.
- Entered values can appear in the page address as shareable state. Do not share or retain that address after adding sensitive incident details.
- Downloaded tables, documents, charts, and structured results can repeat information from the source rows.
- The chart renderer is loaded from a public content-delivery network, but incident rows are not submitted to it for calculation.
Worked Examples:
Blocked action due on review day
With a reference date of May 4, 2026, an action due that day has d = 0 and belongs in the due-soon count. If its status is blocked, the ledger displays Blocked because that rule comes first. Its owner pressure still receives 3 points for blocked, 2 for due soon, and 1 for open, for a total contribution of 6.
References:
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations, National Institute of Standards and Technology, April 2025.
- Postmortem Practices for Incident Management, Google Site Reliability Engineering, 2018.