The incident is resolved, the doc gets written, and the action items are never seen again. Here is the model behind a tracker that closes that loop, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
An incident and postmortem tracker is four parts: an incident record with a timeline captured during the event, a fixed postmortem template, action items that live outside the document, and a trend view across incidents. The action items are the part that decides whether any of this is worth doing. Items that live inside a postmortem document are never revisited, and the same incident recurs six months later with a new document.
Incidents
1
Open right now
9
Action items overdue
4 min
Median to detect
2
Repeats this quarter
Checkout timeouts, Sev 1
Resolved · 2 hours 14 minutes · 1,400 customers affected
Written during, not reconstructed after
You run engineering, operations or reliability. You already write postmortems. What you want is for the action items to get done, and to be able to see whether the same causes keep coming back.
From the first alert to the moment the same thing stops happening.
With the required response, who to notify, and whether a postmortem is mandatory, all attached to the level.
One field, one click, because nobody writes carefully at 3am. Reconstruction from memory produces a tidier and less true account.
Started, detected, acknowledged, mitigated. The gaps between them are where every useful number comes from.
Trigger separated from contributing factors, because most incidents have one trigger and several conditions, and only the conditions are actionable.
Their own records, with owners and due dates, chased weekly. Items inside a postmortem are never revisited.
Which is the most persuasive report an operations team can produce.
This is not a folder of documents. It is four parts, and the third is the one that changes anything.
Severity, services affected, detection method, and the key timestamps: started, detected, acknowledged, mitigated, resolved. The gaps between those are where the useful numbers come from.
Entries added during the incident by whoever is working it, with timestamps, so the postmortem starts from a record rather than from memory.
The same sections every time: what happened, impact, trigger, contributing factors, what went well, what was difficult, and what we are changing.
Records in their own right, with an owner, a due date, a priority and a status, linked to the incident but not buried inside it.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Severity, and a timeline nobody has to reconstruct.
In this Helix project, build me an incident and postmortem tracker.
Severity levels go in a config file: for each, the customer impact that
qualifies, the required response time, who to notify, and whether a
postmortem is mandatory.
An incident records the title, severity, services affected, customer
impact, how many customers, how it was detected, the incident commander,
the communications lead, and four timestamps: started, detected,
acknowledged, mitigated, plus resolved.
Then a timeline that gets written during the incident, not afterwards.
Adding an entry has to take one field and one click, because nobody writes
carefully while an outage is running. Entry types: observation, action,
decision, communication.
Derive time to detect, time to acknowledge and time to mitigate, and show
them separately. Total duration alone hides whether the problem is
monitoring or runbooks, and those need completely different investment.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.So incidents are comparable, and blameless structurally rather than in tone.
Postmortems use one fixed template: summary, customer impact, timeline
pre-filled from the live entries, trigger, contributing factors, detection
analysis, response analysis, what went well, what was difficult, lessons.
Separate the trigger from the contributing factors and allow several
factors. Most incidents have one trigger and a handful of conditions that
made it possible or made it worse, and collapsing that into a single root
cause throws away the actionable half.
Keep the structure blameless. Do not add a field asking who made the
change. Ask what made the change safe to make and hard to catch. A
blameless tone attached to a blame-shaped template produces a blame
analysis anyway, however politely it is worded.
Give it a review state, let people comment on a draft without editing it,
and publish to a searchable archive tagged by service and factor type.Worth knowing. Blamelessness is a property of the fields, not the wording. Remove the field and the analysis changes.
The reason to build any of this.
Make action items independent records, not bullet points inside a document.
Each has a description, a type (prevent recurrence, improve detection,
improve response, reduce impact), an owner, a due date, a priority, a
status, and evidence of completion.
They are created from a postmortem but they live on their own. Publishing
the postmortem does not close them, because publishing is exactly the
moment attention leaves the room.
Do not allow an item without a named owner and a due date. An item owned
by a team is owned by nobody.
Give me an owner view across all incidents, a team view, weekly reminders
for overdue items, and escalation to a manager past a threshold. Then
report completion rate by type and team, and the age of the oldest open
item, which is usually more informative than the average.Worth knowing. Items inside a postmortem are never revisited, and the same incident recurs six months later with a fresh document.
Trends, and the repeat detection that makes the case for investment.
Report incidents by severity, service and month. Tag contributing factors
from a fixed editable list and report them by frequency. That list tells
you where to invest.
Then build repeat detection: incidents sharing a service and a contributing
factor within a window I set. Surface those as repeats.
And when a repeat has an incomplete action item from the earlier incident,
highlight it loudly. That single connection is the most persuasive report
an operations team can put in front of a leadership meeting.
Trend time to detect and time to mitigate per service over time. And build
a quarterly review view that assembles itself: every incident in the
period, the factors behind them, action item completion, and the repeats.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Datadog>. Read the alert that fired and when, which is where time to
detect comes from.
<Jira>. Push action items to where the team actually works, so they are
not orphaned in a document.
<GitHub>. Read what shipped near the incident, which is the first question
anybody asks.
<Slack>. Capture the incident channel into the timeline, so it is not
reconstructed from memory.
<PagerDuty>. Read who was paged and when, which is where time to
acknowledge actually comes from.
<Statuspage>. Read what customers were told and when, so the timeline
includes the communications.
<Zendesk>. Link the tickets the incident generated, which is the honest
measure of customer impact.
<Notion>. Publish the postmortem where engineering already reads, with the
action items linked back.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Incident records hold customer impact and frank internal analysis, so set Access Control before sharing to keep the candid parts internal.
The timeline is written by people during the incident. Everything else can be pulled in.
Datadog
Read the alert that fired and when, which is where time to detect comes from.
Jira
Push action items to where the team actually works, so they are not orphaned in a document.
GitHub
Read what shipped near the incident, which is the first question anybody asks.
Slack
Capture the incident channel into the timeline, so it is not reconstructed from memory.
PagerDuty
Read who was paged and when, which is where time to acknowledge actually comes from.
Statuspage
Read what customers were told and when, so the timeline includes the communications.
Zendesk
Link the tickets the incident generated, which is the honest measure of customer impact.
Notion
Publish the postmortem where engineering already reads, with the action items linked back.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It holds a candid account of failures and customer impact, so access control and ownership are part of the design.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Incident detail includes customer impact and frank internal analysis. SSO means people sign in with their existing account, and access is scoped so the candid parts stay internal.
App Security
Pulling alerts, deploys and service metadata from monitoring and source systems needs real access. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It records incidents with a timeline captured during the event, runs postmortems to a fixed template, and tracks the resulting action items as independent records with owners and due dates.
Because publishing the document is the moment attention moves on. Items inside it are never revisited, and the same incident recurs with a new document six months later. Independent records with owners, due dates and reminders are what close the loop.
The trigger is the change or event that started the incident. Contributing factors are the conditions that made it possible or made it worse, such as a missing alert or a slow rollback. Most incidents have one trigger and several factors, and only the factors are actionable.
Structurally. Do not include a field asking who made the change. Ask what made the change safe to make and hard to catch. A blameless tone attached to a blame-shaped template produces a blame analysis anyway.
Time to detect, time to acknowledge and time to mitigate, reported separately rather than as total duration. Slow detection points at monitoring and slow mitigation points at runbooks, and the combined number hides which one you have.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your severity definitions and your list of contributing factor types.
Customer Success
Give escalations a severity, an owner, a communication cadence and a closure record, so the customer hears from you on schedule rather than when someone remembers. Prompts to build it, and what it takes to run it.
IT and Operations
Record every production change with a risk level, an approval proportionate to that risk, and a rollback plan, without turning deployment into a committee. Prompts to build it, and what it takes to run it.
IT and Operations
Request access against a defined catalogue, route it to the system owner, grant it with an expiry, and produce the evidence an access review needs. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.