How to Write an Incident Update (With Examples)

Q: What should the first incident update say?

Acknowledge the customer-visible impact and commit to a next update: "We are investigating reports that [feature] is unavailable. Next update by [time]." You do not need a root cause to publish a useful first update.

Q: Should I apologize in an incident update?

A brief, genuine acknowledgment of the disruption is appropriate, especially at resolution. Keep it short and factual — over-apologizing mid-incident reads as flustered. Save the fuller reflection for the post-incident summary.

Q: How technical should incident updates be?

Public updates should be understandable by a non-technical customer: describe impact and status in plain language. Save technical detail for the internal timeline and the postmortem.

Q: How does Sandglass fit the advice in this guide?

Sandglass handles the continuous side — checks, incidents, alert routing, and a public status page — so the decisions in this guide turn into monitoring you can rely on.

Say what is affected, what changed, and when the next update will arrive.

How to write clear incident updates: lead with customer impact, state what changed, and promise a next-update time — with examples of what to say and what to avoid.

By H. Marcell, Freelance Software Developer

Updated July 17, 2026

H. Marcell is a freelance software developer who builds and runs web services and APIs, and writes about uptime monitoring, incident response, and status-page communication.

What this guide covers

A good incident update lowers customer anxiety and reduces support load; a bad one does the opposite. This guide covers the structure of an effective update, the one commitment that matters most, and concrete examples of language that builds trust versus language that quietly destroys it.

Lead with customer impact, not internal detail.
Publishing early beats waiting for the root cause.
Promise a next-update time, not a fixed recovery time.

A structure that works under pressure

Write every update in the same order so you never have to think about format mid-incident: (1) Impact — what customers cannot do, in their words. (2) Current state — what you know and what you are doing. (3) Next action — the next step and when the next update lands. This ordering front-loads the information customers came for and buries the internal detail they do not need.

Examples: better vs worse

Worse: "We are experiencing elevated 5xx error rates from the upstream gateway and are rolling back a deployment." Better: "Some users are unable to log in. We have identified a recent change as the likely cause and are reverting it now. Next update by 14:30." The better version leads with impact, avoids jargon, and commits to a next update — without promising a recovery time it cannot guarantee.

Say "logins are failing," not "auth service returning 503s."
Commit to a next-update time, not a recovery ETA.
One clear sentence of impact beats a paragraph of internals.

How Sandglass supports the practice

Write updates in a fixed order — impact, current state, next action — and publish them on your status page so customers have one place to check. With Sandglass backing components with live checks, the page shows measured state automatically, leaving you to focus each written update on the narrative customers actually need.

Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

Customers lose trust when updates over-explain internals or promise recovery times the team cannot defend. "The Kubernetes control plane is degraded" means nothing to most users; "logins are failing" means everything. And a missed "back in 10 minutes" promise does more damage than admitting you do not yet have an ETA.

Implementation checklist

Step 1: Start from customer impact

Decide which failures in this topic actually reach customers before adding any monitoring.

Step 2: Choose one signal per risk

Match each risk to a single HTTP, content, TCP, SSL certificate, or heartbeat check instead of stacking duplicates.

Step 3: Assign an owner and a channel

Give each alert one owner and one destination — email, a Slack webhook, or a generic webhook.

Step 4: Review after real incidents

Revisit intervals, thresholds, and ownership once a real incident shows what was missing.

Frequently Asked Questions

What should the first incident update say?

Should I apologize in an incident update?

How technical should incident updates be?

How does Sandglass fit the advice in this guide?

Monitor how to write an incident update (with examples) with Sandglass

Start free

Free plan, no credit card required.