Incident Communication Best Practices: What to Say During an Outage (With Templates)

Incident communication: status page updates and templates that work

A practical guide to incident communication, with status page update timing guidance, ownership rules, and copy-and-paste templates for UK-based teams.

When a confirmed, customer-impacting incident hits, your first status page update should go out within roughly 5-10 minutes, even if you don't have all the answers yet. That target shifts depending on severity and how confident you are in the scope, but the principle holds: acknowledge the problem, state what you know so far, and promise a specific time for the next update. Silence, more than the outage itself, is what erodes customer trust.

I know that sounds almost too simple. When something breaks, our instinct as engineers and founders is to fix it first and explain it later. But here's what I've learned from watching outages play out, both my own and other companies': customers can handle a broken product for a while. What they struggle with is not knowing whether anyone has noticed. Once you understand that distinction, incident communication stops feeling like a distraction from the real work and starts feeling like part of it.

This guide explains why communication gaps are so damaging, who should own status page updates internally, and how to use practical templates during a real incident.

Who owns incident communication and status page updates?

Before getting to the wording, it's worth settling who is actually allowed to publish an update. Most teams skip this step, which is exactly why the first status page update during a real incident is often late.

A workable model looks like this:

• One person owns the status page during the incident, usually the incident commander or on-call lead, not whoever happens to be free.
• Support gets briefed before or alongside the public update, so your team isn't caught flat-footed when tickets start arriving.
• Engineering feeds facts to the communicator, not the other way round. The person writing the update shouldn't be the same person who's elbow-deep in logs.
• Have a backup communicator: if your incident commander is also your only engineer, decide in advance who posts updates when they're heads-down.
• Agree in advance which channels get what. Use the public status page for customers and internal Slack for the team. If you're a UK company with contractual SLAs, make sure account managers know before customers do, not after.

None of this needs to be elaborate. A single paragraph in your incident runbook naming roles is enough. What matters is that nobody is improvising this decision while the API is on fire.

Why silence during an outage backfires

Here's a scenario I'd bet sounds familiar. Your API starts throwing 500 errors. Your monitoring catches the problem quickly, but your status page still says "All Systems Operational" in cheerful green text. Customers refresh that page every few minutes, watching it say nothing while their integrations fail in real time.

Think about what happens on their side. They don't know if this is a five-minute blip or a five-hour outage. They don't know if you're aware, or if it's just them. So they open a support ticket. Then another, just in case the first didn't go through. Then they post in your community Slack or on social media, hoping someone there has an answer. Your team ends up handling a flood of duplicate tickets on top of actually fixing the problem, exactly the workload spike you can't afford during an incident.

Google's Site Reliability Engineering guidance on emergency response makes a similar point: communication should start as soon as customer impact is confirmed, even when the root cause is still unknown. You don't need certainty to be useful. You need honesty about what you know right now.

Atlassian's incident communication guidance recommends separating confirmed facts from hypotheses in every update: what's affected, who's affected, what customers should do in the meantime, and when they'll hear from you again. You don't need a theory about the root cause in your first message. You need presence.

Cloudflare's June 2022 outage write-up is a good real-world example of getting this right at scale. When a configuration change disrupted service across multiple data centres, the team published a public timeline as events unfolded, then followed with a detailed post-mortem once the facts were verified. Acknowledge now, explain later: that sequencing is worth copying, whatever size team you're running.

This is also why a branded, publicly accessible status page matters, separate from whatever internal dashboard your team uses. It's the single source customers can check instead of guessing, which keeps your support inbox from becoming an accidental press office.

What should the first status page update say?

Once you've confirmed customer impact, the first status page update should include the following.

1. Acknowledge the issue in plain language. "We are aware some users are experiencing errors" beats vague corporate phrasing. Don't dress it up.

2. State what's specifically affected, and how confident you are in that scope. Not "some services" but "API requests to /v2/webhooks are returning 500 errors for a subset of accounts." If you're not yet sure whether it affects everyone or a subset, say that too. It's more honest than false precision.

3. Give customers something to do, if there's anything to do. Offer a workaround, suggest customers hold off retrying, or simply say "no action is needed, we're on it." If there's genuinely nothing they can do, say so rather than leaving the question unanswered.

4. Give a realistic time for the next update, not a resolution time. "Next update in 15 minutes" is honest. "Fixed in five minutes" is a promise you probably can't keep, and broken promises hurt more than slow fixes.

5. Be careful with detection timestamps. Including when you first noticed the issue is useful and shows you were monitoring, not scrambling. But skip it if it could reveal something sensitive, like a longer detection gap than you'd want to advertise. A short internal note explaining the delay is often more useful than a public timestamp.

6. Skip the jargon. Save connection pool exhaustion and configuration rollback details for the post-mortem.

Here's a status page update template that reflects all of that:

We're investigating [issue] affecting [service/function] for [affected users or regions]. [If applicable: no action is needed on your end / workaround: X]. Next update by [time].

It's short and honest, and it tells customers exactly what to do in the meantime.

How often should you post status page updates during an incident?

The golden rule is: under-promise on speed and over-communicate on frequency. Customers forgive slow fixes more readily than they forgive broken promises about timing.

How often you update depends on severity. There's no single correct interval for every incident, but this is a reasonable starting framework:

Severity	Example	Update cadence
Critical, widespread outage	Core product unusable for most users	Every 15 minutes
Partial degradation	One feature or endpoint failing	Every 20-30 minutes
Regional issue	Single data centre or region affected	Every 30 minutes, or when scope changes
Minor issue	Cosmetic bug or small subset of users affected	One update at detection and one at resolution

Whatever cadence you choose, the rule that matters most is this: honour the next-update time you promised, even if nothing has changed. "Still investigating, no new information" is a completely legitimate update. It tells customers you haven't gone dark; you're still working on the problem.

If an incident runs for more than an hour, it's reasonable to space updates further apart. Your team needs time to fix the problem, not just write status posts every 15 minutes. Be explicit about the new cadence when you change it.

What you want to avoid entirely is guessing at a resolution time you can't support. "Should be fixed soon" followed by 90 minutes of silence does more damage to your credibility than a longer, honest estimate ever would.

Use your actual monitoring data to inform updates rather than gut feelings. If multi-region checks confirm the issue is isolated to one region, say exactly that: "We have confirmed this is affecting our EU-West region only; other regions are unaffected." That's more useful to customers than a generic "we are looking into it", and it's the kind of detail good monitoring gives you the confidence to state publicly.

How to communicate resolution and root cause

The moment your monitoring confirms services are stable, post a resolution update. Don't wait for a full investigation to say "we're back up." Customers need to know the immediate crisis has passed, even if deeper analysis takes another day or two.

Resolved as of [time]: [Service] is operating normally. We'll publish a full summary within [timeframe].

Should you explain the root cause publicly?

Generally, yes, but keep the first explanation simple. Save database replication specifics or the exact configuration rollback sequence for a written post-mortem. Customers care less about the mechanics and more about whether you understand what happened and are preventing it from happening again.

If the cause traces back to a third-party dependency, like a DNS provider, hosting region, or expired SSL certificate, say so plainly. "We identified that our upstream DNS provider experienced a service disruption" is honest and reasonable. Customers understand that vendors sometimes fail; they want to know you're paying attention.

A few things are worth flagging with care rather than glossing over:

• Avoid blaming individuals or teams publicly. Focus on systems and fixes. GitHub's 2018 database incident report is a good model: clear, chronological and focused on what happened to the system, without pointing fingers internally.
• If the incident involves a possible security or data issue, slow down before publishing. Under UK GDPR, the ICO expects notifiable personal data breaches to be reported within 72 hours of becoming aware. That's a regulatory clock, not a customer-communication one, but it means security-related incidents often need legal or compliance sign-off before public wording goes out. Coordinate before posting anything that touches customer data.
• Don't speculate. If you're not certain of the cause, say "we're still confirming the root cause" rather than guessing publicly and having to walk it back.

Post-incident follow-up and post-mortems

Once services are stable, the work isn't quite finished. Here's how to close the loop properly.

1. Aim to publish a written post-mortem within 24-48 hours, while details are fresh. Treat that as a target rather than a hard rule. Incidents involving security review, legal input or third-party forensics often genuinely need longer, and it's better to be accurate than fast.

2. Structure it simply: explain what happened, what was affected, the timeline of detection and resolution, the root cause, and the concrete next steps to prevent recurrence.

3. Know the difference between a customer-facing summary and an internal review. The public version should stay high-level and blame-free. The internal version can go deeper, including anything that shouldn't be shared externally, such as security specifics or vendor contract details.

4. Link the post-mortem from your incident history on the status page so customers, and your future team, can find it later.

5. Mention specific preventative measures. Did you add new monitors, adjust alerting thresholds, or add checks for a cron job that failed silently? Say exactly what changed.

6. Do a short internal review too. Incident communication is a skill teams improve with practice, not something anyone gets perfectly right the first time.

Incident communication templates you can reuse

The worst time to write a status page update from scratch is mid-outage, when your team needs you fixing things, not wordsmithing. Save these templates somewhere everyone can find in seconds.

Detection (standard):

We're investigating [issue] affecting [service/function] for [affected users/regions]. Next update by [time].

Detection (scope unclear):

We're aware of reports of [issue]. We're still confirming the scope and will share what we know by [time].

Update (incident in progress):

Update [time]: We've identified [partial cause/scope] and are working on a fix. Next update by [time].

Update (regional or partial issue):

Update [time]: This issue is affecting [specific region/feature] only. Other regions/features are unaffected. Next update by [time].

Third-party dependency:

Update [time]: We've traced this to an issue with [vendor/provider]. We're monitoring their status and will update as soon as service is restored on their end.

No new information:

Update [time]: Still investigating, no new information yet. Next update by [time].

Resolution:

Resolved [time]: [Service] is back to normal operation. We'll share a full summary shortly.

Post-mortem opener:

On [date], [service] experienced [duration] of downtime affecting [scope]. Here's what happened and what we're changing.

Scheduled maintenance:

We'll be performing planned maintenance on [date] from [time] to [time] ([timezone]). [Service] may be briefly unavailable during this window.

Drop these templates into a shared document or wherever your team looks first when something breaks, alongside your escalation rules and status page login details. Whatever monitoring and status page tooling you use, the templates matter more than the platform. Having them ready means nobody is starting from a blank page at 2am.

Incident communication FAQ

What should the first status update say during an outage?

Keep it short and honest: acknowledge the problem, name what's affected and how confident you are in that scope, mention anything customers should or shouldn't do in the meantime, and commit to a specific time for your next update. You don't need to know the cause yet; you need to show you're aware and working on it.

How often should I post updates during an incident?

It depends on severity. A widespread outage might warrant updates every 15 minutes; a partial or regional issue can stretch to every 30 minutes. The interval matters less than honouring the time you promised. If you said 15 minutes, post again at 15 minutes even if the update is "no change yet."

Should I explain the root cause publicly?

Generally, yes, but keep it simple at first: a brief line in your resolution update followed by a fuller post-mortem within a day or two. If the incident touches customer data or security, hold off on public root-cause detail until legal or compliance has weighed in. Accuracy matters more than speed in those cases.

What if we don't know the scope of impact yet?

Say that directly rather than guessing. "We are still confirming which accounts are affected" is a legitimate first update. Customers accept uncertainty about scope far more readily than confident statements that later turn out to be wrong.

What if a third-party vendor caused the outage?

Name the dependency plainly once you've confirmed it, and be clear about what you can and can't influence. "We are monitoring their status page and will update as soon as service is restored" sets realistic expectations without over-promising a fix timeline that isn't yours to control.

Here's the thing about incident communication: it's not about having perfect answers. It's about showing up consistently while you find them. Customers are remarkably forgiving of downtime when they trust you're on it, and far less forgiving when they're left wondering whether anyone noticed at all.