Draft Incident Updates From a Verified Timeline

Feed the workflow a reviewed timeline, state what is unknown, and require the incident lead to approve every customer-facing update.

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. Compare the draft with all five checks below and keep failures in manual review.

node --env-file=.env request.mjs incident.json incident-result.json

Download request.mjs · Download incident.json · Node.js · Model access keys

Use a timeline that someone has checked

The downloadable incident.json is the primary start-to-finish exercise: it already contains the instruction and fictional timeline. Keep it unchanged for the first run, including its English output. The 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.

Check the saved draft against the fixture

Download the expected checks. This is a review checklist, not a model response or an automatic factuality score. Record pass or fail for every check beside the saved draft:

1. Impact: says that some report exports fail. Fail an invented outage scope, affected customer count, upload failure or data-loss claim.
2. Cause: remains unknown or under investigation. Fail any asserted root cause, including a plausible internal theory.
3. Action: the team is investigating and has paused the affected export worker. Fail an omitted pause, an invented mitigation, completed repair or recovery claim.
4. Next update: explicitly gives 09:30 UTC as the next communication. Fail if it becomes a restoration deadline or if the timezone is missing.
5. Approval: no publication, sending or status change occurs. Keep the draft local until the incident lead approves every sentence.

A missing field, unsupported claim or failed check keeps the draft in manual review. Passing these fictional checks does not establish reliability during a live incident.

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:05 UTC — Some report exports fail.
09:12 UTC — Team is investigating and has paused the affected export worker.
09:30 UTC — Next update promised.
ROOT CAUSE — unknown.

ILLUSTRATIVE SAFE DRAFT (not recorded model output)
Some report exports are failing. We are investigating and have paused the affected export worker. The cause remains unknown. We will provide another update by 09:30 UTC.

NOT ALLOWED
"Exports 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.

Later: adapt an existing server-side integration

After the downloadable exercise passes, you can use the same instruction in an approved client built from the Serverless Inference request setup. Replace [approved events] with a reviewed timeline, including explicit unknowns and the next update time. Re-run all five checks and save the reviewed input with the draft. This is an alternative integration path, not a second prerequisite for the fixture.

Frequently asked questions

Can it write the postmortem too?

It can help organize verified material, but the incident team should own causal analysis, accountability, and remediation commitments.

Why include the next update time?

Customers need to know when they will hear from you again, even when the team does not yet know the resolution time.