How to Write an Outage Notice While the Outage Is Happening

Something is down. Customers are noticing. Somebody has to write the notice, and that somebody is usually also involved in fixing it.

That combination produces a recognizable style: heavy on apology, light on fact, full of words like “intermittent” and “some users” that were chosen to avoid committing to anything. It is written by a person trying not to be wrong while not yet knowing what is true.

The 2026 pattern of frequent AI and cloud service degradations means more teams are writing these more often. Vendors themselves have had a great deal of practice this year, and reading how a provider handles it in their own channels, such as the Anthropic newsroom, is a faster education than any template.

It is worth having the structure ready before you need it, because you will not compose it well at 09:20 with three people asking for updates.

The Four Things People Need

Everything else is optional.

What is broken, in their terms. Not “elevated error rates in the ingestion pipeline”. What can they not do.

Since when. A timestamp. This lets people match it against what they experienced and stop wondering whether it is their setup.

What still works. The most useful and most frequently omitted item. If half the product is fine, saying so prevents half your support volume.

When they will hear from you next. A specific time, and you send at that time whether or not there is progress. This is the commitment that buys you quiet.

Cause and remedy are not on the list. People want them, and they can wait. The four above are what determine whether someone can plan their next hour.

The Example

Before:

Hi all,

We’re aware that some users may be experiencing intermittent issues with certain parts of the platform. Our engineering team is actively investigating and working hard to resolve this as quickly as possible. We sincerely apologise for any inconvenience this may cause and thank you for your patience. We’ll provide an update as soon as we have more information.

After:

Rewrites through Wrivio Cloud have been failing since 09:14 UTC. Requests return a connection error.

Local mode is unaffected. If you have a model downloaded, switch the engine toggle to Local and your rewrites will work normally.

We have identified the cause and are deploying a fix. Next update at 11:00 UTC, whether or not it is resolved by then.

No customer data was affected.

Four short paragraphs. Someone reading it knows immediately whether they are affected, what to do instead, and when to check back.

The first version contains one piece of information, which is that something is wrong, and the reader already knew that. “Some users may be experiencing” is a sentence constructed so that no part of it can be proven false.

The Phrases That Cost You

“Some users may be experiencing.” Hedged twice. If you do not know the scope, say “we are confirming the scope” and give a time.

“Intermittent issues.” Almost always means “we do not have a clean characterization yet”. Say what you have observed instead.

“Working hard to resolve.” Assumed. Occupies a line that could hold a fact.

“We’ll update as soon as we have more information.” Not a commitment. It permits silence for six hours. Give a clock time.

“We sincerely apologise for any inconvenience.” One short apology is appropriate. This particular phrasing signals a template, and templates signal that nobody is personally attending to it.

Updates Are Where Trust Is Won

The first notice matters less than the discipline afterwards.

Send at the time you said, even with nothing new. “No change since 09:14. Still working on it. Next update 12:00” costs you thirty seconds and it is the message that stops people escalating, because it proves someone is watching.

When it is resolved, say so plainly and separately, with the resolution time. Do not bury a resolution in a status page nobody has open.

A short follow-up afterwards is worth writing if the outage was material: what happened, what you changed, and what would prevent it. That is a different document with a different audience and it should not be attempted while the incident is live. The internal version of it is in how to write an incident report at work.

For planned work, the structure is different and the notice goes out days ahead: see how to write a maintenance notice. Confusing the two is common and unhelpful, because a planned-maintenance tone applied to an unplanned failure reads as evasive.

The Context For This

Outage notices are written under time pressure, which is exactly when a stored instruction earns its place.

A Wrivio Context for incident notices could say:

Rewrite this as a factual service incident notice. Lead with what is broken and since when, then what still works, then a specific time for the next update. Keep every timestamp, system name, and figure exactly as written. Do not add apologies beyond one sentence, do not add hedging words such as “may be”, “some users”, or “intermittent”, and do not speculate about the cause. Keep the result no longer than the input.

Press Ctrl+Shift+Space, paste the draft, and check the diff. Watch for the rewrite reintroducing softeners. Models trained to be agreeable will put “we apologise for any inconvenience” and “some users may be affected” back in, because that is what the register looks like in most training data. The diff makes it obvious, and this is a case where the model’s instinct is reliably wrong.

Related, and worth reading if the outage moved a customer commitment: how to tell a customer about a delay.

Prepare It Before You Need It

Fifteen minutes now, on a normal day:

Write the template with the four elements and blanks for the specifics. Decide who is authorized to send it without approval, because an approval chain during an incident guarantees the notice is late. Decide the update cadence in advance, hourly for a major outage, and hold to it.

Then the version you send at 09:20 is a fill-in rather than a composition, which is the difference between a good notice and the one at the top of this post.

Common Questions

How quickly should the first outage notice go out?

As soon as you can state what is broken and since when. You do not need the cause or an estimate, and waiting for either is what produces the vague first notice.

Should I say what caused it?

Not in the first notice. Early cause statements are frequently wrong and retracting one costs more credibility than the delay does. Save it for the resolution note or the follow-up.

What if there is no progress at the update time?

Send anyway. A short “no change, next update at X” is the message that proves someone is attending to it and stops people escalating.

Should I apologise?

One sentence, once. Repeated or elaborate apology displaces the information people need and reads as a template.

Download Wrivio for Windows to keep a stored Context for incident notices, so the version you send under pressure is the one you planned when you were calm.