This guide covers a software-service report assembled from mixed notes and logs. Follow your organization's actual incident process for response and escalation. The example is an authored practice packet, not a real outage or a claim that ChatGPT processed production logs.
Supply the timestamps with their offsets
These records concern a fictional catalog-download service on November 3, 2026:
| ID | Original record | Supported reading |
|---|---|---|
| L1 | 2026-11-03T14:02:00Z: release completed | A deployment event at 14:02 UTC. |
| T1 | 2026-11-03T09:04:00-05:00: case C17 reports failed download | A report at 14:04 UTC, not an established failure start. |
| T2 | 2026-11-03T14:05:00Z: copied escalation of case C17 | Another record of the same case; not another established affected person. |
| N1 | 09:06: responder says download failed | Date and offset absent in the note; placement remains unresolved. |
| V1 | 2026-11-03T14:12:00Z: one browser download check passed | A passing check in that tested context. |
T1's offset means add five hours to its displayed time: 09:04 at UTC minus five is 14:04 UTC. Keep both strings and the conversion basis in the review table. Do not assign N1 the same offset just because its time looks similar.
Keep impact counts separate from record counts
T1 and T2 are two records linked to C17. The packet establishes one distinct case ID. It does not establish a total affected-user count, the number of failed requests, or how many people saw the issue without reporting it.
The interval from T1's report to V1's check is eight minutes. That is a report-to-check interval. The packet does not establish when failures began or when service recovered for everyone. A sentence saying “all users experienced an eight-minute outage” would add both a population and a duration the evidence does not contain.
Google's postmortem guidance describes recording incident impact, response, causes, and follow-up, with review of the resulting account. Here, the timeline reconciliation is preparation for that record. A release preceding a report does not by itself establish a cause.
Draft a bounded update
An appropriate practice update is:
A failed catalog download was reported in case C17 at 14:04 UTC on November 3. The escalation at 14:05 refers to that same case. One browser download check passed at 14:12 UTC. The first failure time, affected population, and recovery across other contexts remain unconfirmed. A responder note marked 09:06 still needs its date and time offset confirmed.
That wording tells the next reviewer what is known and which evidence remains missing. It leaves the deployment event in the timeline without declaring it the cause.
Copy a reconciliation-first prompt
OpenAI's prompting guidance, checked October 24, 2026, supports specifying sources, output, and boundaries. For an incident report, the boundaries should protect the original records and uncertainty:
Prepare a draft software incident report from these permitted records.
Service/incident ID and audience: [ENTER]
Records with stable IDs and unchanged timestamp strings: [PASTE]
Established timezone/offset conventions: [PASTE OR UNKNOWN]
Known duplicate/case-linking rules: [ENTER]
Supplied tests and their actual scope: [PASTE]
First produce a reconciliation table: record ID, original timestamp,
normalized UTC timestamp only if supported, conversion basis, event,
source and uncertainty. Keep ambiguous times unresolved. Link duplicate
case records without deleting the originals. Report records, distinct
cases and affected users as separate quantities; use UNKNOWN when needed.
Then draft a concise update from supported findings. Separate event,
detection, report and test times. A passing scoped check must not become
universal recovery. Do not invent cause, impact, duration or remediation.
List the exact missing evidence. Do not change the incident system,
send updates or perform production actions.
Confirm the gaps before the next update
Ask the responder to confirm N1's date and offset. Ask the service owner what evidence establishes the actual impact and recovery scope. Record those answers beside the original records, then revise only the statements they support.
Use the incident-review agenda when the team is ready to discuss the evidence and follow-up. Keep the report in the maintained incident record so the next update can distinguish a new observation from a cleaner retelling of the same incomplete packet.