BlogPost
Incident update templates, and how often to post them
Copy-ready templates for every phase of an incident (investigating, identified, monitoring, resolved and scheduled maintenance), with the cadence that keeps customers informed without filling the page with noise.
7 min readTaha Al-Jody
The hardest incident update to write is the first one. You know something is wrong, you do not know why, and a blank text box is waiting for words that thousands of customers will read. Templates take the writing out of the critical path. You fill in facts instead of composing prose, and every update has the same shape, so customers learn where to look.
This post gives one template per phase, the facts each one needs, and a cadence for posting them. Copy them into your runbook and adjust the wording to your own voice.
What every update needs
Whatever the phase, a useful update answers five questions:
- What is affected. Name the service the customer buys ("Checkout", "Public API"), not the component that broke.
- What the customer sees. Errors, slowness, delays, a feature missing. Describe the symptom, not the mechanism.
- Since when. A start time in a named time zone. "Since 14:05 UTC" beats "for a short while".
- What you are doing. Investigating, rolling back, watching a fix.
- When the next update comes. A time, not "soon".
Leave out anything a customer cannot act on: hostnames, internal service names, error codes from your own logs, and guesses about the cause. A guess that turns out wrong costs more trust than saying you do not know yet.
Investigating
Post this as soon as you have confirmed customer impact. Speed matters more than detail. You can say very little, as long as it is accurate.
Title: Elevated errors on Checkout
We are investigating errors affecting Checkout. Since 14:05 UTC, some customers see failed payments when completing an order. Other services are working normally. We will post an update by 14:35 UTC.
Fill in:
- The affected service and the symptom, in the customer's words.
- The start time. Use the time impact started, not the time you noticed. If your monitoring has a timestamp for the first failing check, use that.
- Scope, if you know it: "some customers", "customers in the EU region", "all API requests". If you do not know the scope yet, leave it out rather than guess.
- The time of the next update.
Do not write "We are aware of an issue" with nothing else. It confirms a problem without telling anyone whether it affects them.
Identified
Post this when you know what is wrong and have a plan to fix it. "Identified" means the cause is known to you. It does not require publishing the cause in detail.
Title: Elevated errors on Checkout
We have identified the cause of the failed payments on Checkout and are deploying a fix. Customers may still see errors until the fix is complete. We will post an update by 15:00 UTC.
Fill in:
- That the cause is identified, and what you are doing about it (deploying a fix, rolling back a change, failing over).
- Whether impact continues while you work.
- The time of the next update.
How much of the cause to share is a judgement call. A short, plain description ("a configuration change") is usually enough during the incident. The full explanation belongs in the postmortem, once you have checked it.
Monitoring
Post this when the fix is in place and the symptoms have stopped, but you want to watch before you call it over. Observer posts this phase as an Information message, the neutral update type between Identified and Resolved.
Title: Elevated errors on Checkout
A fix has been deployed and payments on Checkout have been completing normally since 14:52 UTC. We are monitoring to make sure the issue does not return. We will post a final update by 15:30 UTC.
Fill in:
- When the symptoms stopped, as a time.
- How long you will watch before resolving.
- That customers who saw failures may need to retry, if that applies.
Keep the monitoring period honest. If the metric that defines the service is back inside its threshold and has stayed there, resolve the incident. Leaving an incident in monitoring for hours after recovery makes the page look worse than reality.
Resolved
Post this when customer impact has ended.
Title: Elevated errors on Checkout
This incident has been resolved. Between 14:05 and 14:52 UTC, some customers saw failed payments when completing an order. Payments have completed normally since 14:52 UTC. Any order that failed during this time was not charged. We will publish a postmortem.
Fill in:
- The full impact window, with a start and an end.
- Who was affected and how, in one sentence.
- Anything customers need to do (retry, check an export, contact support) or an explicit statement that they do not need to do anything.
- Whether a postmortem will follow, and where.
The resolved update is the one customers quote later, in support tickets and in SLA conversations. Make the times precise. If your status comes from measurements, take the start and end from the measured status changes rather than from memory. The SLA credits guide shows why a few minutes either side can change a contractual outcome.
Scheduled maintenance
Maintenance has its own lifecycle: announced, starting, in progress, completed. Each step is short.
Announcement, ideally several days ahead:
Title: Scheduled maintenance: Public API
We will perform scheduled maintenance on the Public API on 21 October from 02:00 to 03:00 UTC. During this window, API requests may fail for up to 10 minutes. The dashboard and Checkout are not affected. No action is needed.
Completed:
The scheduled maintenance on the Public API is complete. All services are operating normally.
Overrun, if it happens:
The scheduled maintenance on the Public API is taking longer than planned. API requests may continue to fail intermittently. We now expect to finish by 03:30 UTC and will post an update by then.
State the expected impact plainly, even if it is "none expected". Customers plan around the announcement, and a contract may require a notice period before a window counts as scheduled. In Observer, a published maintenance window starts and completes on its schedule, and subscribers hear when it is scheduled, when it is about to start, when it completes and if it is canceled.
How often to post
A cadence turns silence into a promise. Customers stop refreshing the page when they trust the next update will arrive when you said it would.
| Phase | Cadence | Why |
|---|---|---|
| First update | Within 15 minutes of confirmed impact | Customers are already noticing. Speed beats detail. |
| Investigating | Every 30 minutes, or sooner if something changes | Long enough to have something new, short enough that nobody wonders if you forgot. |
| Identified | Every 30 to 60 minutes | The plan is known; report progress against it. |
| Monitoring | One update at the start, one at the end | Avoid posting "still monitoring" repeatedly. |
| Resolved | Once, when impact ends | Then link the postmortem when it is ready. |
| Maintenance | Announcement days ahead, then at start, completion and any overrun | Customers plan around the window. |
Two rules matter more than the exact numbers:
- Always say when the next update will come, then meet that time. If there is nothing new, post that there is nothing new: "We are still working on the fix. Next update by 15:30 UTC." A missed update time does more damage than a short update.
- Post when the impact changes, not only on the clock. If errors spread to a second service, or stop, say so straight away.
For incidents that run for many hours, it is fine to stretch the interval to every one or two hours, as long as you say so in the update.
One incident, many updates
Post every update on the same incident rather than opening a new one each time. A single incident with a timeline tells the story in order: what was seen, what was done and when it ended. Separate incidents for each update make the history harder to read and inflate your incident count.
If the incident affects some customers and not others, tell the ones affected. Observer can show an incident only on the pages of the customers it affects and notify their subscribers, so the rest of your customers are not alarmed by an incident that is not theirs.
Start from the measurement
Most of the facts in these templates are measurements: which service, since when, whether it has recovered. When the status page is driven by your own metrics, those facts are already on the record before anyone types. In Observer (on Pro and above), a metric that stays unhealthy can draft the incident the moment its status changes, with the affected services filled in. Drafts are never public: a person reviews the draft and publishes it. Your team then spends its first minutes on the fix and on the parts of the update only a person can write.
If you want to see where measured status comes from, Why status pages lie explains the gap between a typed status and a measured one.