Something is broken, you know roughly which part, and the first thing you owe your customers is a sentence. The default a status page tool hands you is one line, usually "We are investigating an issue", and it carries weight it was never designed to carry, so the update gets written from scratch at the worst moment by the person who is also holding the fix.
This page is the text instead: paste-ready updates with bracketed placeholders, grouped by the moment you are in — knowing almost nothing, knowing the cause, having nothing new to say, resolving it, and replying to the customer who wrote in. The status page, the email and the support reply each get their own version; they are three different registers.
One rule holds the rest together: say something within fifteen minutes of confirming there is a problem, and say when you will speak again. A promised time is a promise.
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 actually see, say what is unaffected, and give a specific time for the next update. Anything that does not serve one of those three jobs can come out.
The "what is unaffected" line earns its place fastest. A customer reading "we are investigating an issue" assumes the worst about every part of your product; a customer reading "billing and the dashboard are unaffected" does not open a ticket.
Three phrases are worth leaving out of every template:
- "We apologise for any inconvenience." It is the sentence people skip. 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 customer who is affected reads it as a claim that they do not matter. Scope it instead: which action, which region, which plan, which endpoint.
- The provider's name, before you have confirmed it. "We believe this is an issue at our hosting provider" is a public accusation with your name on it. Say "a provider we depend on" until you know.
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. A customer who cannot tell the difference between "still working on it" and "forgotten about it" will assume the second.
| 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 | — |
The Google SRE Workbook's incident response chapter separates the person running the response from the person communicating about it, because the two jobs interrupt each other. Where those roles are one pair of hands, the honest adaptation is to make each update cheaper to write rather than post fewer of them.
One template makes that cadence survivable: the update that is later than you said it would be. Naming the missed time costs a sentence and buys back the credibility of every future "next update by".
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 — write "14:30 BST", not "14:30" — because your customers are not all where you are. The punctuation is plain, because these get pasted into tools that mangle typographic quotes and dashes.
Investigating
The first update is the hardest, which is exactly why it should be written in advance. 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 is the same content plus the context an email needs, because it arrives without the page around it:
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 support reply is shorter again; the person reading it has already told you something is wrong. Those replies have their own section below.
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
Once you know the cause you can stop describing symptoms and start describing the fix.
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].
Share enough cause that a technical customer can work out whether their own retry logic will recover, and no further. If you do not yet know whether data was affected, say you are checking.
Monitoring
The monitoring update says two things: the fix is in, and you are not yet claiming victory. If a backlog is draining, give it a time, or customers watching a queue in their own account will fill your inbox.
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 will be read by people who missed the incident, and it will still be in your status page history when a prospect's security reviewer goes looking months later.
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 the reader's real question: whether anything is now their 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. This is the update people search for at three in the morning, and the one to paste 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 this one thin, and get a second pair of eyes on it before it goes out.
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 the one category where the template is a starting point rather than a finished message. In the UK, where personal data may be affected, the reporting clock under UK GDPR is 72 hours from becoming aware; the ICO's breach reporting guidance sets out what that means. Agree the wording with whoever handles legal and data protection in advance, so that review is short rather than blocking.
Replying to "is it down?" tickets during an incident
An open incident does not stop the tickets arriving. These three replies cover the arc, each linking the ticket to the live incident.
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]
The middle paragraph of that last one is the point of the whole set. 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 — specificity, and a named next-update time. 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 same incident opened with "We are investigating reports of impacted performance for some GitHub services", which tells that admin nothing.
Stripe, 29 August 2026 — a back-dated start time and a scoped impact. 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, not at 06:45. Giving the time the problem started rather than the time you noticed it lets a merchant reconcile their own failed payments without opening a ticket. The impact is scoped to a country and a payment type, and the cause attributed to a category of third party.
Slack, 16 June 2026 — plain language, who is not affected, and an ETA. 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."
There is no jargon in it. The symptom is described as a person experiences it, so a user can match it to their own screen, and the third sentence tells everyone on iOS and web they can stop worrying. The follow-up: "A fix is already available and will begin rolling out to Android users tomorrow."
All three are written for someone deciding what to do next. The recurring complaint about delayed status pages on Hacker News lands in the same place: what people remember is the hour of silence in the middle of an outage.
Scheduled maintenance is a different message
Planned work needs its own sequence: an announcement well ahead, a reminder, a note when the window opens, one when it closes, and the message nobody has a template for, which is the one you send when it overruns. Do not reach for the incident templates above; an "investigating" message about something you chose to do reads badly. A guide to scheduled maintenance notification templates is coming; until then, status pages covers maintenance windows and how they appear to customers.
When the status page, the feed and the ticket are the same incident
Templates solve the writing. They do not solve typing the update into more than one place — the status page tool, the mailing list, every open ticket — when hands are shortest.
In StayUpfront the incident is the record, and everything customer-facing is a view of it. You write an 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. Each update carries its own visibility, so an internal note and a public update sit on one timeline. A ticket linked to the incident carries that link, so whoever answers "is it down?" can see the live state without leaving the reply box.
The resolved update is still yours to write. An incident raised by a monitor can close itself once every contributing check has recovered; the message that tells a customer what happened to their Tuesday is a person's job.
Common questions
What should an incident update include?
What you know, what you are doing, and when you will post again. Name the affected component in the customer's language, describe the symptom they can see, say which parts are unaffected, and give a clock time for the next update.
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 and every 30 for a major one; hourly for degraded performance. Post on the interval even when there is nothing new, and say so.
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]. Next update by [time]."
Should you apologise in a status update?
Once, in the resolved message, for the specific disruption. Repeating it in every interim update dilutes it and takes space that could carry information.
How do you write a resolved message?
Give the window with a time zone, what was affected and what was not, the cause in plain terms, the fix, and whether the customer needs to do anything. Add what is changing so it does not recur, or a date for that.
Put these wherever your saved replies live, and fill in your own component names while nothing is on fire.
If you would rather write the update once, StayUpfront keeps the incident, the status page and the tickets it affects as one record. Start a 14-day trial and set your portal up before you need it.