Something is broken, you know roughly which part, and the first thing you owe your customers is a sentence. Below are paste-ready updates for the status page, the email and the support reply.
One rule holds the rest together: say something within fifteen minutes of confirming a problem, say when you will speak again, and keep that time.
What every incident update needs
An incident update needs three things: what you know, what you are doing about it, and when you will say more. Name the affected component in the customer's language, describe the symptom they can see, say what is unaffected, and give a clock time for the next update.
Three phrases to leave out:
- "We apologise for any inconvenience." Apologise once, at resolution, for the specific thing that happened.
- "A small number of users are affected." You rarely know the number early, and the affected customer reads it as a claim that they do not matter. Scope it: which action, which region, which plan.
- The provider's name, before you have confirmed it. Naming them is a public accusation with your name on it. Say "a provider we depend on".
How often to post updates during an incident
Post the first update within fifteen minutes of confirming an incident, then on a fixed interval by severity: every 15–20 minutes for a critical incident, every 30 minutes for a major one, and hourly for something degraded. Post on the interval whether or not anything has changed.
Severity | What the customer is living with | First update | Then, until resolved | If nothing has changed |
|---|---|---|---|---|
Critical | The product, or a core part of it, is unusable | Within 15 minutes of confirming | Every 15–20 minutes | Post anyway, saying there is nothing new |
Major | A specific function is failing, with no workaround | Within 15 minutes of confirming | Every 30 minutes | Post anyway |
Minor / degraded | Slower than usual, intermittent errors, a workaround exists | Within 30 minutes | Hourly | Post at the next interval, or extend the interval and say so |
Resolved, still watching | Everything works, you are not certain it will stay that way | At the moment of recovery | Once more before closing | — |
Where the response and the communication are one pair of hands, as the Google SRE Workbook says they should not be, make each update cheaper to write.
The hardest one to write is the update that is late:
Update - [component], later than we said
We said we would post by [HH:MM BST] and we did not. [One sentence on what took the time: "the rollback needed a second attempt".] Where things stand now: [state].
Next update by [HH:MM BST].
Templates by stage
Square brackets are placeholders, times carry a zone ("14:30 BST"), and the punctuation is plain for tools that mangle quotes.
Investigating
Three severity variants for the status page.
Degraded performance.
Investigating - [component] is slower than usual
Since [HH:MM BST], some requests to [component] have been taking longer than normal to complete. [Concrete symptom: "responses that usually return in under 200ms are taking several seconds".] [Other components] are unaffected and requests are still completing.
We are investigating. Next update by [HH:MM BST].
Partial outage.
Investigating - errors affecting [component]
Since [HH:MM BST], [specific action: "creating a new invoice"] has been failing for some customers with [the error they see]. [Named unaffected areas] are working normally. [Workaround, if there is one.]
We are investigating. Next update by [HH:MM BST].
Major outage.
Investigating - [product] is unavailable
Since [HH:MM BST], [product or component] has been unavailable. Requests are [timing out / returning 503 errors]. This affects [scope: all customers, or customers in the EU region].
We are investigating and will post an update by [HH:MM BST], and every [N] minutes after that until this is resolved.
The email version carries the context an email needs.
Subject: [Product] incident: [component] - investigating
We are investigating a problem affecting [component], which began at approximately [HH:MM BST] on [date].
What you may see: [symptom in the customer's own terms].
What is unaffected: [components still working normally].
What we are doing: [one sentence].
The next update will be posted at [status page URL] by [HH:MM BST]. We will email again when the status changes.
The partial-outage template, filled in:
Investigating - errors affecting the Reports API
Since 07:14 BST, requests to /v1/reports have been returning 500 errors for some customers. The dashboard, the Billing API and scheduled report emails are unaffected. Reports queued before 07:14 are still being delivered.
We are investigating. Next update by 07:45 BST.
Identified
Share enough cause that a technical customer can tell whether their own retries will recover, and no further.
Identified - [cause in plain terms] affecting [component]
We have found the cause of [symptom] on [component]. [One sentence: "a configuration change deployed at 07:02 BST sent a subset of API requests to a database replica that was not ready to serve them".] We are [rolling that change back / deploying a fix] now.
[Component] is still [state]. We will confirm here once [component] is behaving normally again. Next update by [HH:MM BST].
Monitoring
The monitoring update says the fix is in and you are not claiming victory yet.
Monitoring - fix deployed, watching for recovery
[The fix] was deployed at [HH:MM BST] and [component] is now [state]. Error rates have been at normal levels for the last [N] minutes.
We are keeping this incident open while we confirm the recovery holds. [Residual work, if any: "a backlog of queued [items] is still clearing and we expect it to finish by [HH:MM BST]".] Next update by [HH:MM BST].
Resolved
Write this one yourself; it stays in your status page history for a security reviewer to find.
Resolved - [component]
Between [HH:MM BST] and [HH:MM BST] on [date], [what happened, one sentence]. [Who and what was affected: "customers on [plan or region] were unable to [action]".] [What was not affected.]
The cause was [plain-language cause]. We fixed it by [action]. [What is changing so this does not recur, if you know yet - otherwise: "we are reviewing what let this reach customers and will publish a fuller write-up by [date]".]
If you are still seeing anything unusual, open a ticket at [support URL] and mention this incident.
The email version adds the apology and answers whether anything is now the reader's problem.
Subject: [Product] incident resolved: [component]
The problem affecting [component] is resolved. It ran from [HH:MM BST] to [HH:MM BST] on [date].
During that window, [what customers could not do]. [Whether anything needs re-running or re-submitting.]
The cause was [plain-language cause], and we have [fix]. We are sorry for the disruption this caused to your [work / customers / release]. The full timeline is at [incident URL].
Templates for the awkward ones
A provider you depend on is the problem. You cannot give an estimate you do not have.
Identified - [component] affected by an issue at a provider we depend on
[Component] has been [symptom] since [HH:MM BST]. The cause is an ongoing issue at one of the providers we rely on for [function]. We have raised it with them and are tracking their updates.
The fix is not in our hands, so we cannot give you a reliable estimate yet. What we can do is keep telling you what we know: next update by [HH:MM BST], whether or not the position has changed. [Workaround, if there is one.]
You still do not know the cause. Paste this on the interval when nothing has changed.
Update - still investigating [component]
We do not yet know what is causing [symptom]. We have ruled out [things you have ruled out] and are currently looking at [area]. There is nothing new to report since [HH:MM BST].
We will keep posting on the same interval so you can see where we are. Next update by [HH:MM BST].
A potential security issue. Keep it thin, and have someone else read it first.
Investigating - a potential security issue affecting [component]
We are investigating a potential security issue affecting [component]. At this stage we are establishing what happened and what data, if any, was involved. We will not speculate ahead of the facts.
[Action the customer should take now, or: "no action is needed from you at this time".] Next update by [HH:MM BST]. If the investigation confirms that customer data was involved, we will contact affected customers directly.
Security is where the template is a starting point rather than a finished message: a UK personal data breach carries a 72-hour reporting clock under UK GDPR (ICO guidance), so agree wording with legal in advance.
Replying to "is it down?" tickets during an incident
An open incident does not stop the tickets arriving.
First contact, incident already open.
Hello [name],
Yes - we have an open incident for this. Since [HH:MM BST], [symptom], and what you have described matches it.
Live updates are here: [incident URL], and the next one goes up by [HH:MM BST]. You can subscribe there if you would rather have updates come to you than check the page.
I will come back to this ticket when the incident is resolved. If what you are seeing looks different from what is on that page, tell me - it helps.
[Your name]
Follow-up once the cause is known.
Hello [name],
An update on the incident affecting [component]: we have found the cause. [One sentence.] [The fix] is [deployed / in progress], and we expect [what will happen].
For your account specifically: [what they will need to do, or "nothing you have submitted has been lost - the queued [items] will process once this clears"].
Full timeline: [incident URL].
[Your name]
Close-out after resolution.
Hello [name],
The incident affecting [component] was resolved at [HH:MM BST]. It ran from [HH:MM BST] to [HH:MM BST], and during that window [what was affected].
For your account: [what happened to their data or requests, and anything they need to re-run]. I have checked and [what you actually checked].
The write-up is at [incident URL]. I am closing this ticket, but reply here if anything still looks wrong and it will reopen.
[Your name]
A status page speaks to everyone; a ticket reply can say what happened to this customer's data.
Three public updates worth copying
GitHub, 13 August 2026. From the GHEC Team Sync incident, posted at 16:21 UTC:
"GHEC Team Sync is currently degraded for enterprises with personal accounts, causing delays when syncing teams to IdP groups. We have identified the cause of the delays and are working on a mitigation. We will provide an update on our progress at 20:00 UTC."
An admin can tell in seconds whether it is them, and the next update is a clock time rather than "shortly". The incident had opened with "We are investigating reports of impacted performance".
Stripe, 29 August 2026. From the elevated card declines incident, first posted at 06:45 UTC:
"As of 05:15 UTC, some card transactions in Mexico are experiencing elevated declines due to an issuing bank being temporarily unavailable. We're in touch with the card network and will post an update as soon as they become available."
The update begins at 05:15, when the problem started, so a merchant can reconcile their own failed payments. The impact is scoped to a country and a payment type.
Slack, 16 June 2026. From the workflow forms incident, opening update:
"We are aware that some users on the Slack Android app are unable to submit workflow forms that contain a required file upload field. After a file is selected, the Submit button becomes disabled and the form cannot be completed. Users on Slack for iOS and Slack for web are not affected. […] We'll provide an update in 60 minutes or sooner if additional information becomes available."
The symptom is described as a person experiences it, and iOS and web users are told they can stop worrying. The complaint that recurs about status pages is the mirror image of all three: silence.
Scheduled maintenance is a different message
Planned work needs its own sequence, because an "investigating" message about something you chose to do reads badly; status pages covers maintenance windows.
When the status page, the feed and the ticket are the same incident
Templates solve the writing, not the retyping.
In StayUpfront the incident is the record. You write the update once, in the incident you are already working, and it appears on the portal status page and in that portal's feed, which customers can follow per component. A ticket linked to the incident carries that link and shows the live state.
An incident raised by a monitor can close itself once every contributing check has recovered; the resolved message is written by a person.
Common questions
What should an incident update include?
What you know, what you are doing, and when you will post again, naming the affected component and the parts that still work.
How often should you update a status page during an incident?
Within fifteen minutes of confirming a critical or major incident, then every 15–20 minutes for a critical one, every 30 for a major one and hourly for degraded performance.
What do you say when you don't know the cause yet?
Say that, and say what you have ruled out: "We do not yet know what is causing this. We have ruled out [X] and are looking at [Y]."
Should you apologise in a status update?
Once, in the resolved message, for the specific disruption. Repeating it dilutes it.
How do you write a resolved message?
Give the window with a time zone, what was and was not affected, the cause, the fix, and whether the customer needs to do anything.
Fill in your own component names now, while nothing is on fire.
If you would rather write the update once, StayUpfront keeps the incident, the status page and the affected tickets as one record. Start a 14-day trial.