Turn the vague time into an item to verify
“Around eight last night” cannot anchor a timeline. It becomes an item to verify, while the recorded action — recovery after a restart — is kept as fact.
Turn monitoring alerts, chat logs, and timeline fragments into a postmortem: timeline, impact, root cause analysis, follow-up actions, and owner placeholders. No invented timestamps, impact scope, loss figures, or root cause conclusions, no blame, and every unconfirmed item flagged.
We order events by recorded evidence, separate confirmed facts from open questions, keep root cause apart from hypothesis, and write follow-ups with owner placeholders.
SAMPLE OUTPUT
This is the complete output for the source text in the demo above: a completeness score, itemised revisions, what was marked unverified and why, and the structured postmortem. It is a demonstration, not a customer case.
“Around eight last night” cannot anchor a timeline. It becomes an item to verify, while the recorded action — recovery after a restart — is kept as fact.
“Maybe a few thousand” and “probably not small” have no source. They become two fields, affected users and financial loss, each marked as no data and listed for verification.
“Probably a database issue” moves into the hypothesis section with the logs and metrics it would take to confirm it, so it never enters the report as a conclusion.
# Incident postmortem (draft) ## Summary The service was unavailable one evening. Exact start and end times need verification. ## Timeline - To verify: the exact start time (source says “around eight last night”) - To verify: detection and escalation time - [Recorded] Recovery method: service recovered after a restart - To verify: exact recovery time and total duration ## Impact - Affected functionality: pages would not open (source: user reports; exact endpoints to verify) - Affected users: source says “maybe a few thousand”, not counted — to verify - Financial loss: source says “probably not small”; no amount or method given — to verify ## Root cause - Hypothesis (unverified): the source suggests “probably a database issue”; no logs or metrics support it yet - To verify: database monitoring, slow queries, and error logs before concluding ## Follow-up actions - Add monitoring and alerting: owner [to be assigned], due date open - To verify: whether the restart was a temporary mitigation or the actual fix ## Items to verify - Exact start and end time and total duration - Affected user count and how it was counted - Whether any financial loss applies and how it would be calculated - Database metrics and logs during the incident
WHAT DRAFTING DOES
Only timestamps the notes contain get written. Missing ones stay as items to verify rather than being filled with “around eight” or “a while later”.
Affected users, affected functionality, and duration each get their own line. No data means “no data available”, never an estimate.
Verified causes and hypotheses sit in different sections, and a hypothesis is labelled unverified rather than written as a conclusion.
WHY IT IS WORTH DOING
Ten minutes off on the timeline can invert the root cause. An uncertain timestamp is better marked as unverified.
“Probably tens of thousands in losses” reaches the next review deck, and it was never measured by anyone.
Once it says “someone made a mistake”, people stop adding detail and the review ends there.
Note: common practice in incident review is to rebuild the factual timeline first, then discuss causes and follow-ups, and to keep the process blameless. Teams differ in report format, severity levels, and how impact is counted. This site drafts documents only; it verifies no monitoring data and offers no operations or security advice.
DRAFTING DEMO
The service went down last night around eight. Lots of users said they could not open it. Probably a database issue, maybe a few thousand users affected, and the loss is probably not small. We restarted it and it came back. We should add monitoring; Xiao Wang will follow up, as soon as possible.
# Incident postmortem (draft) ## Summary The service was unavailable one evening. Exact start and end times need verification. ## Timeline - To verify: the exact start time (source says “around eight last night”) - To verify: detection and escalation time - [Recorded] Recovery method: service recovered after a restart - To verify: exact recovery time and total duration ## Impact - Affected functionality: pages would not open (source: user reports; exact endpoints to verify) - Affected users: source says “maybe a few thousand”, not counted — to verify - Financial loss: source says “probably not small”; no amount or method given — to verify ## Root cause - Hypothesis (unverified): the source suggests “probably a database issue”; no logs or metrics support it yet - To verify: database monitoring, slow queries, and error logs before concluding ## Follow-up actions - Add monitoring and alerting: owner [to be assigned], due date open - To verify: whether the restart was a temporary mitigation or the actual fix ## Items to verify - Exact start and end time and total duration - Affected user count and how it was counted - Whether any financial loss applies and how it would be calculated - Database metrics and logs during the incident
Demo sample: every “probably” becomes an item to verify, the unproven cause is demoted to a hypothesis, and follow-ups keep an owner placeholder instead of an invented deadline. Paste your notes to get your version (sign-in required; one credit per run).
WHY YOU CAN TRUST IT
Start and end times, duration, affected user counts, and loss amounts read as “no data available” unless you supply them, and then appear as items to verify.
Unverified judgement is labelled a hypothesis and kept in its own section, never mixed into confirmed causes.
Only actions and system behaviour are described. Accusations in the source are rewritten as observable facts.
Submitted text is used for this single AI request and is not intentionally persisted. See the Privacy Policy.
FAQ
No. Affected users, duration, and monetary loss must come from monitoring or finance. If the notes lack them, we write “no data available” and list them for verification instead of estimating.
Yes. Unproven judgement is written as a hypothesis in its own section, and the logs and metrics still needed are listed for verification, so nothing gets concluded for you.
No. The report describes actions and system behaviour only. Blame in the source is rewritten as an observable description of what happened.
One credit per run, usually done in seconds, returning the postmortem, revision notes, and items to verify.
No. Credits never expire — whatever you do not use carries over to the next cycle instead of resetting.
Not yet. Each run processes one document and consumes one credit; there is no bulk upload or API today. Email us with your use case and we will assess it.
Not intentionally. Text is used for this single AI request only. See the Privacy Policy.
Monitoring alert dumps, on-call chat logs, timeline fragments, postmortem meeting notes — any incident material that needs to become a formal report.
SIMPLE PRICING
For an occasional publishing cadence, with a focused monthly credit allocation.
For frequent publishers who iterate on content continuously.
Our largest monthly credit allocation, for the heaviest continuous usage.
Credits never expire: unused credits carry over instead of resetting. Credits apply to this site only and are not shared with other sites.
Prices shown are USD baselines; final currency, taxes, and discounts are determined by Paddle for the checkout location.