Every incident gets a timeline before the post-mortem starts
Describe the incident in your own words and the flow orders what happened against your runbooks, then drafts the timeline, the impact and what is still unknown. Nothing reaches the incident channel in Slack until someone on call approves it.
Engineering · Someone asks · 7 steps · Reads your documents · SlackA person is asked at “Ask a person”
Why teams run it
After an incident, someone has to reconstruct what happened from alert emails, chat scrollback and memory, usually while still tired from the incident itself. Timelines written late are incomplete, and speculation about cause creeps in as fact.
How it is governed
- Nothing reaches Slack until someone on call approves the post.
- A rejected timeline ends the run and is recorded as not sent.
- It is instructed not to speculate beyond the evidence it is given.
- Testing in the builder describes the Slack post without sending it.
- Who runs it
- On-call engineers; Incident commanders; Site reliability leads; Engineering managers.
- What you supply
- Slack connected; Runbooks as a knowledge source.
From template to a live agent
The same builder, tests and release review apply to a template as to anything built from scratch.
- Open it as a working flow
- Every step, source, branch and approval is already in place, and every one of them can be changed before it runs on your data.
- Prove it before it ships
- An evaluation set can gate the release, so a change that breaks an answer never reaches anyone. A question it cannot answer from the sources leaves the gate unproven, not passed.
- Keep a person on the decisions
- A run that needs a decision stops and says exactly what approving will do, and who it is waiting for.
- Publish where people work
- A form, an embedded widget, Microsoft Teams or a scheduled batch — with its own access and limits per deployment.
- What teams usually change
- Change the Slack channel it posts to after approval; Name who approves: the on-call engineer, the incident lead, or a group; Match the timeline format to your post-mortem template.
Questions buyers ask
- Does it read our monitoring tools?
- No. It works from the alerts and messages an engineer gives it, plus your runbooks as a knowledge source. It has no connection to your monitoring or paging tools.
- What happens if the approver rejects the timeline?
- The run ends with a note that nothing was sent, and nothing is posted to Slack. The draft and the decision stay in the run history.
- Will it guess at root cause?
- It states a suspected cause only where the evidence supports one, and lists what is still unknown separately. It is instructed not to speculate beyond what it was given.
Related templates
All 60 templates- Code review copilotReviews a diff against your own conventions rather than generic advice.EngineeringSomeone asks4 steps
- On-call morning digestRuns on a schedule and posts what changed overnight to the team channel.EngineeringOn a schedule6 steps
- API helper over your own APIAnswers questions about your service and can call it — reads run, writes ask a person first.EngineeringSomeone asks5 steps
See it run on your own data
We open it in the builder, point it at a sample of your documents and systems, and run it with you.