What is a status page? 

A status page keeps customers in the loop of a web application’s outages or maintenance schedules. There are two types of status pages: system-wide (external) or incident-specific (internal). An external status page is an information hub for external audiences like customers. An internal status page informs internal stakeholders. It shares updates with parties directly involved in resolving the incident/performing the maintenance, as well as leadership who aren’t directly involved but need to be in the know.

Why is a status page important?

System-wide status pages foster customer loyalty. They explain when and why outages happen — whether caused by unexpected incidents, routine maintenance, or third-party service providers. An outage will inevitably cause some inconvenience and frustration for customers. But, the info on a status page buys some patience and grace from the users. 

An internal status page is crucial because it lets your team quickly communicate important information to the leadership team and other stakeholders. Rather than communicating over Slack channels or emails, involved team members can visit the status page to see updates in real time.

What are some status page best practices? 

When you publish a status page, keep these three best practices in mind:

  • Keep it simple, without frilly graphics, verbiage, etc.

  • Highlight transparency by listing past incidents/resolutions on your site.

  • Know what not to say, such as discussing security-sensitive issues before it’s safe or mentioning small-scale incidents that won’t affect most users.

Keep it simple 

When creating a status page, keep it simple. Stick with general descriptions like “Slack messages are delayed” or “images are unavailable in search results.” These pages don’t need frills — they only need to display the current working status of your products’ core functions. Visitors should be able to get that info at a glance.

Use familiar color signaling to make it easy for customers to gather the necessary information quickly. Teams often use standard color coding on their status pages: green for healthy, yellow for moderate disruption, and red for major disruption. Also think about using iconography to enhance accessibility.

Highlight transparency 

Good status pages also provide a window into past incidents, including how your team solved them. Leave past incidents and resolutions on the page as a scrolling list. Then, a new customer can look at your status page and see all of the incidents you’ve resolved over the years. They’ll see that minor issues are acknowledged publicly — not just total outages — and trust that you’ll communicate when things aren’t working as expected and resolve those issues. 

Know what not to say

While, theoretically, you should feel comfortable alerting customers about all incidents, it isn’t always necessary. For example, FireHydrant had a situation where data in a customer’s third-party integration was repeatedly overwritten due to a configuration issue. Once we confirmed that none of our other customers were experiencing this issue, we determined it was too specific to need a status page update.

In addition, you shouldn’t create a public status update for a security incident where details could put users at risk. However, you should inform users of the incident once you can do so while also meeting your contractual disclosure requirements.

See FireHydrant in action

See how service catalog, incident management, and incident communications come together in a live demo.

Get a demo