A BETTER WAY TO SHARE THE WORK
Turn incident notes into a postmortem people can learn from
Explain what happened and what will change—without turning incomplete evidence into certainty or blame.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
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.
01 / SEE THE DIFFERENCE
Recovered service is not a completed investigation
A fictional report-download incident. Request failures are measured; the unique customer count is not.
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 owns a proposed alert coverage test, not yet accepted or scheduled. No data-loss assessment was supplied.
- Observed impact
- 240 failed requests over an 18-minute observation window; unique affected users are unknown.
- Timeline
- Errors 09:12, alert 09:14, rollback 09:22, recovery confirmed 09:30 UTC.
- Recovery
- Rollback restored downloads. This does not complete the investigation.
- Analysis
- A preceding configuration change is a provisional hypothesis, not a confirmed cause. No data-loss assessment was supplied.
- Follow-up
- Noor owns validation by September 10. Eli's alert coverage test is proposed, not accepted or scheduled.
Open a complete fictional HTML example, with its source notes →
Create my incident postmortem02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
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.
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.
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.
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.
03 / TRY THIS PROMPT
Copy this into your agent. Add your source material.
Use the conversation where you already did the work, or start one with your notes. Replace the placeholders and supply any missing context; only attach information you are allowed to share with your agent.
Get the ready-to-copy creation request for guided questions, this task, and a draft review before anything is published.
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.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- 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.
FROM DRAFT TO A LINK
Make it clear. Make it yours. Then share it.
Keep creating and revising in the agent you already use. With a compatible connection, share/artifacts publishes the reviewed HTML so you do not have to rebuild it in another editor. Ask your agent to use your saved artifact style for headings, color, and tone; review the result before sending it.
Choose who should be able to open the page and verify the returned link. For corrections to the same deliverable, update the existing artifact without changing its link. Publish a separate artifact when the old edition needs to remain available.
These are static pages, not live apps: no scripts, forms, or automatic data refresh. Source collection and scheduling depend on your agent and its available tools, not on share/artifacts.
Make this with my agentQuestions before you start
Must the root cause be known before writing?
No. A draft can preserve the verified timeline and impact while marking analysis incomplete. Do not title a plausible explanation as the root cause merely to fill a section.
Can an internal postmortem be published unchanged?
Not automatically. A wider audience may require a separate reviewed version with sensitive details removed. Confirm both the facts and the disclosure boundary before publication.
Does the page track remediation?
No. It displays a reviewed snapshot and can link to authorized action records. Refresh the page only after reviewing updated evidence; it does not close or synchronize tasks.