The Web Editor Blog

Service copy

Write an outage notice readers can use

Clear incident copy says what is affected, what readers can do and when you will update them. Leave the unverified explanation out.

A red pen beside a marked-up printed text

Lead with the reader’s interrupted task

An outage notice is a small piece of service journalism. Its first job is to tell a reader whether the problem affects what they came to do. Compare a vague apology with a specific statement that the article archive is temporarily unavailable while the home page still works. The second statement helps someone decide whether to wait or try another route. Use plain language and identify the affected feature before describing the organisation’s feelings about the incident.

Give an update time you can own

There is a difference between promising that the service will be repaired by a certain time and committing to post another update then. When the repair estimate is uncertain, make the second commitment. Include the time zone and update the notice even if the investigation is continuing. Google’s explanation of its Search Status Dashboard provides an example of an incident lifecycle that distinguishes investigation, follow-up and mitigation. A small publication can use a much simpler version of that discipline.

Keep technical claims tied to evidence

An editor should not turn a working hypothesis from a support conversation into a public declaration. Say what is confirmed and which service remains affected. If the cause has not been established, leave it open. Keep a private note of the source for every factual update, including its time and the person responsible. That record makes corrections easier and prevents a later editor from treating an early guess as settled background information.

Prepare the hosting questions before the next launch

Planning availability is easier before a major publication than during an interruption. An editor can explore KoDDoS with the technical owner and ask how an availability incident would be reported, which services a proposed arrangement covers and who supplies public updates. Keep the provider decision separate from the wording of a live notice. A product reference is not evidence for the cause of the current incident, nor a reason to insert a sales message into a status update.

Close the notice with an observed result

After the service owner confirms recovery, repeat the reader’s original task and report what is available again. If some features remain affected, name them. Retain a brief dated record where readers would reasonably expect follow-up, and remove banners that no longer describe the current state. If an earlier statement was wrong, correct it visibly. A useful closing notice can be short: the change in availability, any remaining limitation and the next place to obtain help.

Put it into practice

Too vague — fictional example

We are experiencing issues. Everything will be back soon.

Specific — fictional example

The article archive is temporarily unavailable. The home page remains accessible. We are investigating and will post another update by 16:00 UTC, even if the issue continues.

Before publishing a notice, confirm each claim with the incident owner and replace the example time with an actual commitment.

Sources & further reading

Examples and worksheets on this page are illustrative. Documentation links were checked in November 2026; follow the relevant product’s current instructions.