Incident updates

When this helps

Use an incident update when a failure affects someone else’s work: Publishing breaks, an upload stalls, or a service becomes unreliable. Lead with the affected task, not an unexplained internal error.

Give your dot: the incident owner, affected service, evidence sources, approved audience and destination, update cadence, and the checks required before calling it resolved.

What a useful update looks like

Investigating

Publishing is failing.

What we know: the test publish failed. Saving a draft passed. Scheduled publishing has not been checked.

What staff can do: keep saving drafts. Do not repeatedly submit the same publish.

Next: the incident owner is checking the release logs. The cause and recovery time are not confirmed.

In a real post, include the evidence time, time zone, source, and agreed next checkpoint.

Fictional example · not a current outage

Make the indicator mean something

Incident states and the evidence they require
State	What it says
Investigating	An observed symptom is being checked. The cause may be unknown.
Mitigated	A workaround reduces the impact. The underlying problem is not confirmed fixed.
Monitoring	The relevant check is passing again. The agreed observation window is still open.
Resolved	The stated recovery criteria passed for the affected scope.
Unknown	Current evidence is unavailable. Preserve the last confirmed state and its time.

Use words as well as color. Planned maintenance is not automatically an outage. A missing test is not proof a working service is down.

The method

Read before announcing.
Check the current evidence and existing incident thread. Separate what you observed from the cause you suspect.
Write for the people affected.
Name the impact, what still works, what to avoid, and who owns the next step. Give an ETA only when there is evidence for one.
Keep one current summary.
Use the approved thread or message. Preserve a short dated timeline when editing. Do not repost unchanged recaps unless a heartbeat was requested.
Verify the delivery and the recovery.
A sent-call attempt is not delivery. A merged fix is not recovery. Read the message back and test the relevant release and user role before declaring an all-clear.

A broken check is not a broken service

If the dot’s browser cannot start, it cannot use that failure as evidence that your website is down. Report the unavailable check, retain the last confirmed time, and continue any independent work that is still possible.

Reuse existing communication approval for the same scope. That does not authorize deployments, account resets, spending, or new access. A status-writing task should not become an unrequested repair job.

Try it on your own work

Why this exists: I wrote about the times my dots got this wrong in the field report.

Starter prompt · replace the brackets

Use the incident-updates playbook for [service]. Read [primary evidence] and the existing incident thread. Draft a staff-facing update with the observed impact, what still works, what to do now, evidence time, next owner, and next checkpoint. Separate suspected cause from confirmed facts. Reuse the current communication approval for [destination], but do not change systems or access. Do not call it resolved until [recovery checks] pass.

Download the playbook ↓Read the Markdown

Version 0.2.0 · MIT · Copyable workflow instructions, not a native plugin installer. Adapt the inputs and check the tools available in your account. Local page tests are not live dot or connector certification. Manifest.