How to Communicate Website Downtime to Users

Downtime is expensive — not just because your service is unavailable, but because of how it affects user trust. A poorly handled incident, where users are left in the dark or get a delayed, vague explanation, causes more lasting damage than the downtime itself.

The good news: downtime communication is a learnable skill, and the companies that handle it well have developed clear, repeatable patterns. This guide walks through all of them.

Principle One: Communicate Before Users Ask

The worst thing you can do during downtime is wait for users to find out on their own and start asking. By the time your support queue is filling up with "is the site down?" tickets, you've already lost the first communication window.

The goal is to acknowledge the issue before users report it. This requires two things:

1. Monitoring — You need to know about downtime before your users do. Domain Monitor checks your application every minute from multiple locations and alerts you the moment something fails — via email, SMS, or Slack. Create a free account and set up your first monitor. The first alert should reach you, not a user email.

2. Prepared communication channels — You should know, before an incident, how you'll communicate: status page, social media, email list, in-app banner. These channels should be ready before they're needed.

The Status Page

A public status page is the standard way to communicate incidents. It gives users a place to check without emailing support, and it reduces the volume of "is it down for everyone?" messages.

What a good status page shows:

• Current operational status for each major component
• Active incident timeline with timestamps
• Historical uptime record

Keep it on a separate domain or infrastructure from your main application. A status page that goes down during an incident is useless.

Domain Monitor includes a public status page feature — your monitors and their history are displayed automatically. See how to create a public status page for setup instructions.

What to Say (and When)

First Update: Acknowledge the Issue

Post within minutes of detecting the problem. You don't need to know the cause yet — you just need to acknowledge that something is wrong.

Template:

Investigating — [Date, Time] We are aware of an issue affecting [service/feature]. We are investigating and will provide an update shortly.

What this does: users know you're aware. They don't need to email support. They can check the status page for updates.

What to avoid: going silent, being vague to the point of meaninglessness, or waiting until you know the full cause before communicating anything.

Subsequent Updates: Show Progress

Post updates every 15-30 minutes during an active incident, even if you don't have new information. "We're still investigating" is a valid update. Silence isn't.

Template:

Update — [Time] We continue to investigate the issue affecting [service]. Our team has identified [what you know so far, if anything] and is working on a fix. We will update again at [specific time].

The specific time commitment matters. It tells users when to check back and shows that you're actively managing the incident.

Resolution Update: Clear and Specific

Template:

Resolved — [Time] The issue affecting [service] has been resolved. Service was impacted from [start time] to [end time] ([duration]).

The cause was [brief description]. We have [what was done to fix it].

We will share a full post-incident review within [24/48/72 hours] for those affected.

Don't euphemise. "We experienced an unexpected service disruption" is fine; vague language that obscures what actually happened is not.

The Post-Incident Review

For significant incidents — anything that affected users for more than a few minutes — publish a post-incident review. See how to write a post-incident report for a detailed guide.

A good post-incident review covers:

• What happened (timeline of events)
• What the impact was (which users, which features, for how long)
• Root cause
• How it was detected and how long it took to respond
• What you're doing to prevent recurrence

Publishing this demonstrates accountability and seriousness, and is often the factor that preserves trust after a significant incident.

Choosing Your Channels

Status page — Primary channel. All incident updates should go here. Users know to check it.

Email — For incidents affecting paying customers or where users may not see your status page. Keep it factual and professional.

Social media (Twitter/X) — Useful for consumer-facing products with active social audiences. Post brief updates and point to the status page for details. Don't have a full back-and-forth on social during an incident.

In-app banner — If your application is partially functional, an in-app banner alerting users to the issue can reduce support volume significantly.

Slack / Discord community — If your product has a community, a channel message early in the incident keeps community members informed and reduces noise.

Tone and Language

Be direct — Users want to know what's happening, not wade through corporate language. "Our database server failed" is better than "we are experiencing degraded performance across some service components."

Avoid blame — Even if a third party caused the incident, don't lead with that. Focus on what's happening and what you're doing.

Use timestamps — Every update should have a timestamp. Without them, users can't tell how recent the information is.

Don't overpromise on resolution time — "We expect to resolve this by 3pm" that becomes "we expect to resolve this by 6pm" erodes trust faster than not committing to a time. Give estimates only when you have good confidence.

Avoid hedging phrases that obscure — "Some users may be experiencing" when the entire service is down is the kind of language that makes users feel managed rather than informed.

The Communication Starts With Detection

Good incident communication is impossible if you don't know about the incident promptly. Every minute between when your service goes down and when you start communicating is a minute where users are confused, frustrated, and forming a negative impression.

Domain Monitor monitors your website from multiple global locations every minute and sends immediate alerts via email, SMS, or Slack when something fails. The monitoring is the prerequisite for the communication — without it, users always know before you do.

Set up monitoring at domain-monitor.io and connect it to your alerting channels before your next incident. For more on setting up alerting, see how to set up downtime alerts.

Related Articles

• The Ultimate Guide to Website Security for Developers
• VPS vs Shared Hosting - Which Is Right for Your Website?
• The Actual Costs Behind Website Downtime [Shocking Results!]