Guides 5 min read

How to Create a Status Page Customers Trust

A status page tells customers what is broken, what you are doing and when to check back. How to set one up, what to put on it and ready-to-use incident update templates.

A status page is a public or private web page that shows whether your services are working, and what you are doing when they are not. During an incident it replaces a flood of “is it down?” emails with one place to check. Outside incidents it quietly shows your track record. You can set one up in an afternoon. This guide covers what to put on it, how to set it up and how to write updates people actually read.

Why have a status page

When something breaks, customers want three answers: is it just me, do you know about it, and when will it be fixed. Without a status page, they ask support, social media or your sales contact. Each question costs time when you have the least of it.

A status page answers all three at once. It also builds trust: openly communicating an incident usually earns more goodwill than the outage costs.

What to show

Components customers recognise

List the parts of your product the way customers think about them: Website, Checkout, API, Dashboard, Email notifications. Internal names like web-03 or redis-primary mean nothing to them. Group components if you have many.

Current status and history

Show the current state of each component and a history of recent days, so visitors can see at a glance whether today is unusual. Connect components to your uptime monitors, so the status reflects real checks instead of someone remembering to update it.

Incidents and updates

Each incident gets a title, a status (investigating, identified, monitoring, resolved) and timestamped updates. Keep resolved incidents visible for a while, as a record of how you handle problems.

Ways to stay informed

Link to your support channels and social profiles, so people know where else to look.

Setting up your status page

  1. Choose public or private. Public for customer-facing products. Private with a password for internal tools or individual agency clients.
  2. Make it easy to find. Link to the status page from your site footer, help center and login page, so customers know where to look before they write in.
  3. Brand it. Add your logo and colours, so it feels like part of your product. On Uptimecheck Professional and Business plans you can add custom CSS and JS, and on every plan you can remove Uptimecheck branding.
  4. Add components and connect them to monitors.
  5. Decide on indexing. A public status page can be indexed by search engines, or you can block indexing if you prefer it to be found only through links.
  6. Make it easy to find. Link it in your website footer, your help centre and your error pages. A QR code is handy for printed material or physical locations.

An Uptimecheck status page supports all of this: public or password-protected pages, your own branding, blocking search engines, QR codes, social links and removable branding.

Writing incident updates

Clear, regular updates matter more than perfect wording. Some rules:

  • Post the first update within minutes, even if all you know is that something is wrong.
  • Say what customers experience, not what the server does: “Payments fail at checkout”, not “Elevated 5xx on payments-svc”.
  • Say when the next update comes, and keep that promise.
  • Avoid guessing at causes or times you are not sure of.
  • Close with a summary of what happened and what changes.

Templates

Investigating

We are investigating reports that [component] is [symptom, e.g. not loading / returning errors]. We will post an update within 30 minutes.

Identified

We have identified the cause: [short, plain description]. We are working on a fix. Some customers may still see [symptom]. Next update at [time].

Monitoring

A fix has been deployed and [component] is working again. We are monitoring to make sure it stays stable. Next update at [time].

Resolved

This incident is resolved. Between [start time] and [end time], [what customers experienced]. The cause was [cause]. To prevent this from happening again, we are [changes]. We are sorry for the disruption.

Planned maintenance

On [date] between [start] and [end] ([time zone]), [component] will be unavailable while we [reason]. [What customers should do, if anything.]

After the incident

The resolved update is not the end. Within a few days, publish a short post-incident summary for significant incidents:

  • What customers experienced and for how long.
  • What caused it, in plain language.
  • What you changed so it does not happen again.

Keep blame out of it and focus on facts and fixes. Customers rarely expect perfection, but they do expect you to learn. A history of honest summaries on your status page is one of the strongest trust signals you can offer.

Hosting the status page

A status page that goes down with your product is worse than none. Host it separately from your main infrastructure, so it stays reachable when your servers, your DNS provider or your hosting company has a problem. A hosted status page from your monitoring provider does exactly that, and it connects directly to the checks that detect the outage.

Learning from status page analytics

During an incident, traffic to your status page shows how many customers are affected and how they found out. Status page analytics in Uptimecheck show visits by continent, country and city, referrers and UTM parameters, devices, browsers, languages and visit times. If most visits come from one country, the problem may be regional. If many arrive through a link in your support auto-reply, that link is doing its job. See status page analytics.

For agencies: one status page per client

Agencies can give each client their own status page on the client’s domain, showing only that client’s sites. Clients check the page instead of calling, and the agency looks in control. Group each client’s monitors and status page in a project to keep things tidy.

Status page checklist

  1. Choose public or password-protected.
  2. Link to the page from your site footer and help center.
  3. Add your logo and colours.
  4. List components in customer language and connect them to monitors.
  5. Link the page from your footer, help centre and error pages.
  6. Save the incident templates where your team can find them.
  7. Agree who posts updates and how often.
  8. Review analytics after each incident.

Summary

A good status page is simple: recognisable components, real-time status from your monitors and honest, regular updates. Set it up before you need it, so it is ready the next time something breaks.

Status pages with analytics are included on every Uptimecheck plan. Try it free for 14 days, no credit card required.

Questions

Should a status page be public or private?

Public for products with many customers, so anyone can check without logging in. Private, protected by a password, for internal systems or for an agency's individual clients.

Where should the status page be hosted?

Separately from your main infrastructure, so it stays up when your product is down. Link to it from your site and help center so customers can find it.

How often should I post updates during an incident?

Post the first update within minutes and follow up at regular intervals, for example every 30 minutes, even if nothing has changed. Say when the next update will come.

Can I see how many people visit my status page?

With Uptimecheck status page analytics you see visits by continent, country and city, referrers and UTM parameters, devices, browsers, languages and visit times.

Keep reading

Downtime is obsolete.

Set up your first monitor in under a minute and know before your customers do.

14-day free trial · No credit card required

Start free trial