Incident notes into a postmortem

State what happened.
Never fill in the gaps.

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.

Evidence onlyNo guessed causeNo blame
01

Paste incident notes

0 / 12,000 charactersMinimum 80

Content is used only for this AI request and is not intentionally stored by this site.

02

Review the postmortem

Your result will appear here

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

Here is exactly what you receive.

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.

SAMPLE

Postmortem result (sample)

Completeness score88/100
+50
01

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.

02

Replace estimated numbers with no data available

“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.

03

Demote the unproven judgement to a hypothesis

“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.

Structured postmortem
# 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

A postmortem is worth its facts, not its phrasing.

01

Order the timeline by evidence

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”.

02

Split impact into separate fields

Affected users, affected functionality, and duration each get their own line. No data means “no data available”, never an estimate.

03

Keep cause apart from hypothesis

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

Write one postmortem wrong and the outage repeats.

01

A wrong time yields a wrong cause

Ten minutes off on the timeline can invert the root cause. An uncertain timestamp is better marked as unverified.

02

Invented loss is impossible to retract

“Probably tens of thousands in losses” reaches the next review deck, and it was never measured by anyone.

03

Blame shuts the flow of information

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 same incident notes, organised.

Before

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.

Drafted
# 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

We put “no invented facts” into our product principles.

Times and numbers are never filled in

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.

Root cause only with support

Unverified judgement is labelled a hypothesis and kept in its own section, never mixed into confirmed causes.

No blame wording

Only actions and system behaviour are described. Accusations in the source are rewritten as observable facts.

Content is not stored

Submitted text is used for this single AI request and is not intentionally persisted. See the Privacy Policy.

FAQ

Ask these before you pay.

Will you estimate affected users or losses?

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.

Can you draft it before the cause is known?

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.

Will it say whose fault it was?

No. The report describes actions and system behaviour only. Blame in the source is rewritten as an observable description of what happened.

What does one draft cost?

One credit per run, usually done in seconds, returning the postmortem, revision notes, and items to verify.

Do credits expire?

No. Credits never expire — whatever you do not use carries over to the next cycle instead of resetting.

Is there batch processing or an API?

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.

Is my content stored?

Not intentionally. Text is used for this single AI request only. See the Privacy Policy.

What content fits?

Monitoring alert dumps, on-call chat logs, timeline fragments, postmortem meeting notes — any incident material that needs to become a formal report.

SIMPLE PRICING

Prove the value before you upgrade.

Starter

$9/ month

For an occasional publishing cadence, with a focused monthly credit allocation.

  • 50 optimization credits per monthly renewal
  • Complete GEO analysis
  • Chinese and English output
  • Markdown export

Advanced

$79/ month

Our largest monthly credit allocation, for the heaviest continuous usage.

  • 1,000 optimization credits per monthly renewal
  • Complete GEO analysis
  • Chinese and English output
  • Markdown export
Loading localized prices

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.