Status Page and Outage Communication: A Practical Guide

A status page is a public web page where you report whether your service is working, and it is the single place customers should be able to check during an outage. Post early, even before you know the cause, update on a regular schedule you state in advance, write in plain language about what customers are experiencing, and close every incident with a clear resolution note and, for serious ones, a written review. Silence during an outage does more damage than the outage itself.

Customers generally forgive downtime more readily than they forgive feeling ignored. The status page is how you show them someone is on it.

What a status page is for

A status page answers one question quickly: “Is it me, or is it them?” When it works, customers stop filing duplicate tickets, support teams can point to one link, and journalists or social media posts quote your words instead of guessing.

A useful status page usually shows:

• Components customers recognize: “Login,” “Payments,” “Mobile app,” “API.” Not internal system names.
• Current status for each component, such as operational, degraded performance, partial outage or major outage.
• Active incidents with timestamped updates.
• Scheduled maintenance, announced ahead of time.
• Incident history, so customers can see how often problems happen and how you handled them.
• A subscribe option for email, SMS, RSS or chat notifications.

Host it separately from your main infrastructure, on a different domain or provider. A status page that goes down with the product is worse than none.

When to post: declare early

The most common mistake is waiting until you understand the problem. By then customers have already noticed, filled your support queue and started posting on social media.

1. Set a trigger in advance. For example: post once monitoring confirms customer impact, or as soon as support receives several reports of the same problem. Write this into your crisis communication plan so nobody has to debate it at 2 a.m.
2. Give one person the job. The engineers fixing the issue should not also be writing updates. Name an incident communicator for each shift.
3. Post the first update fast. “We’re investigating” is a complete and useful first message.
4. State when the next update will come and keep that promise, even if the update is “no change yet.”

What every update should include

• What customers are experiencing, in their terms: “Some customers can’t log in,” not “elevated 5xx rates on auth-service.”
• Who is affected: all users, a region, a plan, a feature.
• What you’re doing, in a sentence.
• Any workaround customers can use now.
• When the next update will be.

Leave out speculation about the cause, blame on a vendor you haven’t confirmed, and estimated fix times you can’t stand behind. If you give a time and miss it, the next update has to start with an apology for the estimate.

Templates for each stage of an incident

These use a fictional invoicing app, Ledgerly. Adapt the components and timing to your service.

Investigating

We’re investigating reports that some customers can’t send invoices. Viewing and editing invoices is working normally. We’ll post an update within 30 minutes.

Identified

We’ve identified the cause: a problem with our email delivery provider is preventing invoice emails from sending. Invoices are saved and nothing has been lost. As a workaround, you can download an invoice as a PDF and send it yourself. We’re working with the provider on a fix and will update within 30 minutes.

Monitoring

A fix has been applied and invoice emails are sending again, including those queued during the incident. We’re monitoring to make sure delivery stays normal. If an invoice you sent earlier today still hasn’t arrived, please resend it from the invoice page.

Resolved

This incident is resolved. Between 9:10 a.m. and 11:25 a.m. Eastern, some customers were unable to send invoices by email. All queued invoices have now been delivered. We’re sorry for the disruption to your billing day. We’ll publish a summary of what happened and what we’re changing within a week.

Beyond the status page: other channels

Not everyone will think to check a status page. Point people to it from wherever they already are.

Channel	What to do during an outage
In-app banner	If the app loads at all, show a short notice linking to the status page.
Social media	Post a brief acknowledgment with the link, then keep detailed updates on the status page to avoid two versions drifting apart.
Support channels	Add an auto-reply and a support macro with the link, so agents aren’t typing the same answer over and over.
Email	Reserve for serious or long incidents, or for customers directly affected, such as those whose data or payments were involved.
Account managers	Contact large customers personally. They should never learn about a major outage from a public post.

If the incident involves customer data, it may be a security incident with legal notification requirements, and the status page is not the right place for those details. Our guide on data breach communication covers that situation.

Common mistakes

• A page that says “All systems operational” during an obvious outage. Nothing destroys trust in a status page faster. Automated green lights need a human override.
• Going quiet for hours. If you promised an update in 30 minutes, post one, even to say the team is still working on it.
• Jargon. Write for the least technical customer who might read it.
• Understating impact. Calling a total outage “degraded performance” is noticed, screenshotted and remembered.
• Quietly editing old updates. Add new timestamped updates rather than rewriting what you said earlier.
• Deleting incidents from history. A visible history of problems honestly handled builds more confidence than a suspiciously clean record.

The post-incident review

For significant incidents, publish a written review once you understand what happened. Many engineering teams call this a postmortem. It turns an outage into evidence that you take reliability seriously.

1. Summary: what customers experienced, for how long, and who was affected.
2. Timeline: key moments with timestamps, including when you detected the issue and when you first told customers.
3. Cause: explained in plain language, with technical detail further down for those who want it.
4. What went well and what didn’t, including your communication.
5. Changes you’re making, with owners and rough timing where you can commit to them.
6. An apology, specific to the impact.

Blameless reviews, which focus on systems and processes rather than on individuals, tend to produce better fixes and more honest public write-ups. Never name an employee as the cause in a public review. If customers were materially affected, a direct note often matters as much as the review; our guide to writing a customer apology email has templates.

A worked example

This is an illustrative scenario, not a real client.

A booking platform for fitness studios goes down on a Monday morning, the busiest time for class check-ins. Its monitoring alerts fire within minutes, and the on-call engineer starts investigating. The support lead, who is the named incident communicator, posts “Investigating” on the status page and pins a short post on social media linking to it. Account managers message their largest studio chains directly.

Updates go out every 20 minutes as promised. The second update includes a workaround: studios can export the day’s roster as a spreadsheet and check people in manually. The service is restored before midday, the resolved note gives the exact window, and a review published four days later explains that a database change caused the failure and that such changes will now be rolled out to a small share of traffic first. Several studio owners reply to the post thanking the company for keeping them informed. Some are still frustrated, which is normal, but the conversation is about the fix rather than about being ignored.

Setting up a status page before you need one

• Choose hosted or self-hosted, and make sure it runs on separate infrastructure.
• List components the way customers describe your product.
• Write templates for each incident stage and for scheduled maintenance.
• Decide who can post and who approves, with backups for nights and weekends.
• Link it from your help center, app footer and support auto-replies.
• Run a practice incident so the team has used it at least once before a real outage.

For software companies, reliability shows up in reviews on software comparison sites too. Our page on SaaS reputation management covers how outages and support experiences feed into that. If an outage has turned into a wider public problem, our crisis management service can help.

Frequently asked questions

Should a small business have a status page?

If customers depend on your online service to do their own work, yes. Even a simple page, or a pinned post on a channel customers already follow, gives people somewhere to check and reduces support load during a problem.

How often should we update the status page during an outage?

Set an interval and state it in each update. Frequent updates early in an incident help, and you can stretch the interval once a fix is in progress. The key is to post when you said you would, even if nothing has changed.

Should we say what caused the outage?

Not until you’re confident. During the incident, describe the impact and what you’re doing. Explain the cause in the resolved note or the post-incident review, once it’s confirmed.

Should we offer credits after an outage?

Check your service agreements first, since some contracts set out credits for downtime. Beyond that, it’s a business decision. If you offer something, say clearly who qualifies and how they receive it, so the offer doesn’t create a second round of support tickets.