Job post-mortem-draft-from-your-incident-record · revised 12 October 2026
Draft your blameless post-mortem from the incident thread, every timeline entry sourced
A draft post-mortem where every timeline entry cites a message, log line or commit you supplied, causes are hypotheses with evidence labels, and action items are listed. Names appear as roles.
You might be seeing
- The timeline lives only in a chat thread
- People disagree on the order of events and nobody has the sources open
No passwords, keys, card details or admin invites needed to start.
What usually happened
A good post-mortem needs a timeline built from evidence, not memory. Writing it from a long thread and logs takes hours the team does not have, and a drafting tool can state a cause with confidence that the evidence does not support, or put names on blame.
Who it’s for: A small engineering team that has just had an outage and has no time to write the post-mortem.
Usually starts when: An incident is over, the thread is long, and the write-up keeps slipping while memory fades.
The result: You receive a draft post-mortem in which every timeline entry cites a message, log line or commit you supplied, causes appear as hypotheses with an evidence label, and action items are listed. A source index lists every artifact used. Names appear as roles unless you say otherwise.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- The draft post-mortem
- The source index
- The list of gaps in the record
Included
- One incident, with the exported thread, relevant logs and commits you supply
- A timeline in which each entry cites its source
- Causes as hypotheses, each labelled shown, likely or unproven
- Action items as proposals, not decisions
- A source index and a list of gaps in the record
Not included
- Deciding the root cause or who was at fault
- Notifying customers, regulators or insurers
- Records that hold personal data or HR content
- Advice on whether the incident was a notifiable breach
- Facilitating a review meeting
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every timeline entry cites a message, log line or commit from the supplied record, checked by script for a source on every entry.
Evidence: The script check and the source index.
Your incident lead checks 10 entries chosen by script with a fixed seed against their sources and finds each supported (the true rate is then at least 74% with 95% confidence). An entry whose cited source does not say it fails the whole check.
Evidence: The 10 entries, their sources and the lead's verdicts.
No cause is stated without an evidence label of shown, likely or unproven.
Evidence: A script search for unlabelled causes.
Names appear only as roles unless you asked otherwise.
Evidence: A script search of the draft for names from the record.
Sign-off. Your incident lead reads the draft and signs off in writing. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- The thread and logs exported by you, with personal data removed
- A named incident lead who checks 10 sampled entries
- An incident that has ended
We stop and tell you if
- The record holds personal data or a possible notifiable breach: stop and use your data-protection process
- The incident is still running
- The record is too thin to date events
What could go wrong
The job writes a document and changes nothing. Our copies of your records are deleted when the job ends. Provider retention is named in the agreement.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A hallucinated cause is read as established. | No cause appears without an evidence label, and the label "unproven" is used where evidence is thin. |
| The record holds personal data or HR content. | You remove it before export, and the job stops if a possible breach is involved. |
| Thread text carries instructions meant for the model. | The incident thread, logs and documents are treated as data: the model gets the text and returns drafts a script checks, with no tools, no network and no secrets. |
A separate automated reviewer checks the work before hand-over. Your named incident lead checks 10 sampled entries against the sources. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the incident, the sources and how names appear
- Receive the exported thread, logs and commits
- Build the timeline; cite a source for every entry
- Write causes as hypotheses with evidence labels; list action items as proposals
- Separate automated reviewer checks citations; your lead checks 10 entries
- Hand over the draft, source index and gaps list
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
To turn lessons into runbooks, the runbook job can follow.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Use a post-mortem template and fill the timeline in a short meeting while the thread is open.
- Ask the incident lead to write only the timeline with links and add causes later.
Questions
Will it say who caused the outage?
No. It is blameless and uses roles. Causes are hypotheses with evidence labels.
Can we send the whole Slack channel?
Send an export of the incident thread only, with personal data removed.
Do you tell customers or regulators?
No. You decide what to publish or report.
Send an enquiry
Send us
- What happened in a few lines and how long the thread is
- Whether personal data is involved
- No thread text, logs or logins in the first enquiry
Later, once you agree
- The exported thread and logs, with personal data removed
- The commits and deploy times
- The name of your incident lead
You keep the records and decide what the post-mortem says; we work from an export you make. The incident thread, logs and documents are treated as data: the model gets the text and returns drafts a script checks, with no tools, no network and no secrets. Our automated agents read the files you send in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “post-mortem-draft-from-your-incident-record” as the subject.