Recovered is not the same as understood.

How can an agent help write an incident postmortem?

Give it the verified timeline, impact measures, mitigation record, and reviewed analysis. Ask for a clear account that separates observations from causal hypotheses and service recovery from permanent remediation. Have the incident owners verify it, remove sensitive operational details, then share the approved static reading page.

What to give your agent

• A reconciled incident timeline with explicit timezone and the evidence behind key events.
• Approved impact measures with units, measurement windows, coverage limits, and unknowns.
• The actions taken during response and evidence of recovery, separate from proposed permanent fixes.
• Reviewed contributing factors, open questions, and follow-up records with confirmed owners and status.

1. Define impact before telling the story

   State the affected service, observation window, and what was measured. Failed requests are not necessarily unique affected users. If customer coverage or data loss is unknown, preserve that uncertainty rather than writing a reassuring absolute.

2. Reconcile the timeline

   Use one explicit timezone and retain conflicts in the source record for review. Separate detection, response, recovery, and confirmation. Do not infer that the first alert was the start of impact, or that a mitigation immediately restored every user.

3. Separate causes from plausible explanations

   Summarize the reviewed system conditions and evidence without assigning motives to people. A change occurring before an outage is not proof that it caused it. Keep hypotheses and unresolved causal analysis labeled, and do not expose secrets or exploitable infrastructure details in a wider-audience version.

4. Make follow-through verifiable

   List what was done to recover service and what still needs work. For follow-ups, preserve an owner, intended verification, and agreed date if supplied. Keep proposed tasks distinct from accepted tasks and completed tasks distinct from proven prevention. The tracker remains the source for changing status.

Keep creating and revising in the agent you already use. Start with a saved artifact style and learn how to update HTML without changing its link.

Use the conversation where you already did the work. Only attach material you are allowed to share.

Create an incident postmortem from only the verified and authorized incident materials I provide. Ask for missing essentials: incident scope, timeline timezone, impact units and window, recovery evidence, reviewed analysis, and follow-up ownership. Separate observed facts from hypotheses and recovery from permanent remediation. Preserve conflicting timestamps and unknown impact for review. Do not infer unique affected users from request counts, assert no data loss without evidence, assign blame, invent causal certainty, or mark proposed work completed. Include confirmed owners and supplied dates, with agreed versus proposed status. Keep secrets, exploit details, personal data, and sensitive infrastructure information out of the audience-facing draft. Create static HTML without scripts, forms, or live monitoring claims. Use my saved artifact style if available. Return the draft with unresolved questions. Do not publish or change access without separate explicit approval. Do not perform remediation or modify incident records as part of drafting.

• Do impact units and time windows match the underlying evidence?
• Are detection, recovery, and investigation state distinct?
• Are causal hypotheses labeled rather than asserted as findings?
• Do follow-ups preserve confirmed ownership and proposed versus accepted status?
• Have operational secrets and inappropriate details been removed for this audience?

When HTML fits

A reviewed incident explanation for colleagues or an approved external audience, with a concise impact summary and evidence-led detail below.

When another format fits better

Use established incident tooling for active response, monitoring, alerts, and action tracking. Keep confidential investigation material in its approved system. This workflow is not security-incident advice, an emergency response tool, or a guarantee that recurrence is prevented.

Recovered service is not a completed investigation

A fictional report-download incident. Request failures are measured; the unique customer count is not.

The original notes

September 7 UTC: download errors observed 09:12; alert 09:14; rollback started 09:22; recovery confirmed 09:30. There were 240 failed requests during the 18-minute observation window; unique affected users are unknown. A configuration change preceded impact, but causal analysis is provisional. Rollback restored downloads. Noor owns validating the configuration hypothesis by September 10; Eli is the proposed owner of an alert coverage test, not yet accepted or scheduled. No data-loss assessment was supplied.

The page can be decisive about recovery while remaining honest about what the team has not yet established.