How to Communicate Downtime to Your Customers

Every service goes down eventually. Hardware fails, deploys go wrong, third-party providers have their own bad days. The question isn’t whether you’ll have downtime — it’s how you’ll handle it when it happens.

The companies that communicate well during outages come out the other side with stronger customer relationships. The ones that go silent, downplay the issue, or pretend nothing happened? They lose trust that takes months to rebuild — if they get the chance at all.

This guide covers what to do, what to say, and how to set up systems so that good communication happens by default, not by accident.

The cost of silence

When something breaks and you say nothing, your customers fill the silence with their own conclusions — and those conclusions are almost always worse than reality.

Support tickets explode. Every affected customer submits their own report. Your support team spends hours responding individually to the same issue, copying and pasting the same reply, while your engineering team is trying to fix the actual problem. It’s an enormous waste of time on both sides.

Social media fills the gap. If customers can’t find an official update, they head to Twitter or community forums. “Is [your product] down for anyone else?” threads spread fast, and the narrative is entirely out of your control. Speculation and frustration compound.

Churn accelerates quietly. Not every unhappy customer complains. Some just leave. They make a mental note that your service went down and nobody told them, and the next time they evaluate alternatives, that memory tips the scales. Silence is expensive — you just don’t see the invoice until later.

The fix is straightforward: communicate early, communicate honestly, and communicate through the right channels.

Best practices for downtime communication

Acknowledge fast, even before you have full details

You don’t need to know the root cause before you say something. A simple “We’re aware of an issue affecting [service] and are investigating” posted within minutes of detection is infinitely better than silence. Customers don’t expect you to have all the answers immediately. They expect you to be paying attention.

Be honest about what’s affected and what’s not

Vague updates like “We’re experiencing some issues” aren’t helpful. Be specific: which services are down, which are degraded, and which are completely unaffected. If your API is down but your web dashboard works fine, say so. Customers can make better decisions with better information.

Give regular updates, even if nothing has changed

“Still investigating” is a valid update. If 30 minutes pass without a word, customers start wondering if you’ve forgotten about the issue or if things have got worse. Set a cadence — every 15 to 30 minutes during an active incident — and stick to it. Each update reassures customers that real people are actively working on the problem.

Provide estimated time to resolution when possible

If you have a reasonable estimate, share it. “We expect to have this resolved within the next hour” gives customers something to plan around. If you genuinely don’t know, say that too: “We don’t have an ETA yet but will update as soon as we do.” Honesty beats false precision every time.

Post a follow-up after resolution

Once the incident is resolved, don’t just mark it as fixed and move on. Post a brief summary: what happened, what you did to fix it, and what you’re doing to prevent it from happening again. This doesn’t need to be a full post-mortem (though those are valuable too). Even a few sentences show customers you take reliability seriously and learn from your mistakes.

Communication channels

Not every channel is right for every situation. Here’s how to think about each one:

Status page — your foundation. This is the single source of truth. It’s always available, always current, and customers can check it on their own terms. Every other channel should point back here. If you only set up one communication channel for incidents, make it a status page.

Email notifications. For customers who’ve subscribed to updates, email is direct and reliable. It’s especially important for major outages where customers may not think to check your status page. Keep emails concise — a brief description, current status, and a link to the status page for ongoing updates.

Social media. Use this for major, widespread outages. A quick post on Twitter/X acknowledging the issue and linking to your status page handles the “Is it down?” crowd before it spirals. Don’t try to run your entire incident communication through social media — it’s too noisy and too hard to keep organised.

In-app banners. If parts of your application are still accessible, an in-app banner is an excellent way to reach users who are actively using your product. Keep it brief: what’s affected and where to find more details.

The status page ties everything together. It’s the canonical record of what happened and when. Every other channel is a pointer back to it.

Incident update templates

When an incident kicks off, you don’t want to be wordsmithing from scratch under pressure. Here are four templates you can customise and use immediately:

Save these somewhere your on-call team can grab them quickly — or better yet, use a status page tool that has templates built in so you can post updates in seconds, not minutes.