Draft Incident Updates From a Verified Timeline
Create calm, accurate status-update drafts from confirmed incident facts while keeping incident command in charge.
Use a timeline that someone has checked
This is a tabletop evaluation playbook for incident drafts. Complete the linked Serverless Inference request setup before the exercise. Use fictional facts first; this guide does not connect or publish to a status page.
A status update should come from confirmed timestamps, customer impact, mitigation steps, and the next check-in time. Exclude speculation, internal blame, secrets, and logs that customers cannot use.
Assign one incident lead to mark each fact confirmed, uncertain, or rejected. The model gets only the confirmed facts and an explicit statement of what remains unknown.
- Run the harmless example in the linked setup from an approved server-side client.
- Replace its user message with the status-update instruction below. Replace [approved events] with only the confirmed timeline from the example, including the unknown cause and next update time.
- Save the returned draft locally. Check each claim against the timeline and verify 09:30 UTC is the next update, not a restoration promise. Have the incident lead approve the text; leave publication to the usual manual process.
Ask for a draft with strict boundaries
DigitalOcean Serverless Inference is useful for a short server-side request during uneven incident traffic. It lets the application send a direct model request without running inference infrastructure, but it does not maintain session state. Include the complete approved context every time.
Keep the model access key in a server-side secret store. Never paste it, a customer list, or production credentials into an incident prompt.
Write a customer status update using only confirmed facts below. Include: impact, what we are doing, and next update time.
Do not name a root cause unless it is confirmed. Do not promise a resolution time. If a field is unknown, say it is under investigation.
Confirmed timeline: [approved events]Make approval part of the path
The incident lead checks every sentence against the timeline, then publishes through the normal status-page or support process. The workflow may prepare a draft. It must not send, change, or close anything.
Save the approved timeline and final text together. After the incident, compare drafts with the actual sequence and revise the instruction where it introduced ambiguity.
CONFIRMED TIMELINE
09:04 UTC — Some customers cannot upload files.
09:12 UTC — Team is investigating.
09:30 UTC — Next update promised.
ROOT CAUSE — unknown.
SAFE DRAFT
We are investigating an issue that is preventing some customers from uploading files. Our team is working to understand the cause. We will provide another update by 09:30 UTC.
NOT ALLOWED
"Uploads will be restored by 09:30 UTC."
"The issue was caused by [unconfirmed theory]."Practice before the next outage
Run a tabletop exercise with a past incident. Include one changing fact, one unknown, and one misleading internal theory. The draft should stay honest under all three conditions.
Accept the draft only when every claim matches the approved timeline.
Run the fictional example
Install Node.js 22 or later on your computer. Download the request helper and input file below into a new private folder. In the Model Catalog, choose a text model with chat-completions support and create a model access key restricted to that model. Copy its exact model ID.
Create a file named .env in that folder using a text editor. Put DIGITALOCEAN_TOKEN= followed by your key on the first line, and DIGITALOCEAN_MODEL= followed by the model ID on the second. Keep this folder outside a repository and do not share .env. Open a terminal in the folder and run the command below. Each run uses billed model tokens.
Open the result JSON in your editor and read its draft field. It is a proposal awaiting review. HTTP errors, empty answers and truncated responses exit unsuccessfully. Use a new output filename for another run. If JSON was requested, parse the draft separately and reject missing fields, duplicate or unknown IDs, unsupported claims and invalid categories. Keep failures in the manual review list.
node --env-file=.env request.mjs incident.json incident-result.jsonCheck your result
- Expected result
- The incident lead can trace every sentence to a confirmed timeline item and publish through the normal channel.
- Stop if
- Stop if the draft adds a resolution estimate, root cause, customer list, or internal detail not in the approved timeline.
- Next step
- Save the approved draft beside the timeline and use the gap review to improve the next exercise.