Use the word outage only when the service was fully down. For anything less, say incident or service degradation, and describe the effect in plain terms. PagerDuty's public guidance makes this point because customers who read outage tend to assume the worst. Always review the external message before it is sent.
The guidance
PagerDuty's postmortem process tells the owner to write the external message for customers, to have it reviewed in the postmortem meeting before it goes out, and to avoid the word "outage" unless it really was a full outage, preferring "incident" or "service degradation". It also suggests looking at earlier postmortems for examples of what to send.
The wording point is about accuracy as much as tone. If the service was partly available, saying it was down overstates the problem. If it was fully down, a softer word understates it. Either way you lose trust.
A quick wording guide
| Situation | Suggested wording | Avoid |
|---|---|---|
| Service fully down | "The service was unavailable from 14:02 to 15:10 UTC." | "Brief hiccup" |
| Some features slow or failing | "A service degradation affected the export feature." | "Outage" |
| Security event with no known data access | "We investigated a security incident. We have found no evidence that customer data was accessed." | "No impact" before you know |
| Cause still unknown | "We are investigating the cause." | A guess |
| Third party involved | State the facts you have confirmed | Blaming the vendor |
The "no evidence" line only works if it is true at the time you write it, and you update it when facts change. Check with legal for security events.
What an external message should contain
- What happened, in a sentence.
- Who was affected and what they may have seen.
- When it started and when it was resolved, in one time zone.
- What you did.
- What customers need to do, if anything.
- What you will change, in general terms.
- When you will update them next.
For the larger decision about what to publish and what to hold back, see public postmortem for customers. For status page timing, see when to post an incident on your status page.
Steps
- Draft the external message alongside the internal postmortem, not after it.
- Have it reviewed in the postmortem meeting, as PagerDuty does.
- Check each factual claim against the timeline.
- Remove adjectives and speculation. See do not speculate in public.
- Get the named approver to sign off. See who approves public incident communications.
- Send, and note the time in the postmortem.
Mistakes to avoid
- Minimising to calm people. Understating costs more than the incident later.
- Overstating to sound serious. It creates alarm and calls from customers you did not need to worry.
- Promising what you cannot confirm. Say what you know now.
How Safeguard fits
For supply chain events, a precise list of affected components makes customer statements accurate. Safeguard's SBOM and dependency scanning helps, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is incident a softer word for breach?
No. They mean different things, and legal definitions of breach vary. Use accurate terms and take advice on security events.
Who approves the wording?
Name an approver in advance, as part of your incident communications plan.
Sources
Last reviewed: 19 October 2026.
