Mistakes To Avoid With Your Public Status Page
Introduction
A public status page forms the public face of your organization's service availability. It is the first point of contact for your customers to check the status of your services during times of crisis. Hence, ensuring the credibility and uptime of your public status page is crucial to your organization's reputation.
In this article we will look at the key mistakes to avoid while hosting and managing a public status page.

- Introduction
- Public Status Page - Expectations
- Uptime Mistakes to Avoid
- Provider Mistakes to Avoid
- Credibility Mistakes to Avoid
- Transparency Mistakes to Avoid
- Communication Mistakes to Avoid
- Actionability Mistakes to Avoid
- Discoverability Mistakes to Avoid
- Conclusion
Public Status Page - Expectations
What do your customers and users expect from a public status page?
The important things are:
- Uptime. The status page should be up and running at all times.
- Reliability. The status page should be hosted by a reliable provider if you are using a managed provider.
- Credibility. The status page updates should be managed by your team and reflect the actual status of your services and have a history of being open about incidents and maintenance.
- Transparency. The status page should be honest about the actual status of any ongoing incident or maintenance.
- Communication. The status page should be updated with clear and concise information in a timely manner.
- Actionability. The status page should provide guides and workarounds, if any, for customers.
- Discoverability. Last but not least, users should be able to find the status page easily, either from your website home page, from your support portal, or from your social media channels.
To meet these expectations, you have to ensure that the status page's importance is appreciated across your organization.
Uptime Mistakes to Avoid
Hosting the Status Page on the Same Infrastructure
Think about it - if the same Google Cloud zone that hosts your primary application hosts your status page, and that zone goes down, your status page will be down along with your applications. You would have no way to update the status page. Cloud providers have zonal and regional isolation to limit the impact of outages. If you are hosting your status page yourself, use this fact and deploy your status page in a different zone or region.
However, if you are using a managed provider, this is usually out of your control. At best, you can check with the provider if they host their infrastructure in the same cloud provider as yours or in a different zone or region. If you are using a managed provider, they will usually ensure that they have high availability for their customers' status pages.

Screenshot from Heroku's June 10 outage summary.

Screenshot from Google Cloud post-mortem.
Sharing a DNS Provider With Your Primary Domain
Your status page would probably be hosted on something like status.yourdomain.com
where yourdomain.com
is your primary domain.
This leaves your status page vulnerable to outages in your DNS provider.
Strategies to follow here in order of increasing risk:
- Use a different registrar for your status page domain. This naturally implies a different domain. You also have to ensure that you choose a different DNS provider as well. You can configure your DNS provider's root servers in your registrar settings. Why a different registrar? See the Zoom outage example below.
- Use a different domain with the same registrar but a different DNS provider.
- (Not recommended) Host your status page on a subdomain of your primary domain.
Zoom Outage - April 16, 2025
Zoom's status page is hosted at https://status.zoom.us/
. On April 16th 2025, due to a communication error between Zoom's domain registrar and GoDaddy, the zoom.us domain was shut down.
The NS records were removed at the TLD level, resulting in DNS clients like browsers and native apps unable to resolve the zoom.us domain as well as any subdomains. As a result, their status page was also unavailable.
The outage lasted around 2 hours.
Provider Mistakes to Avoid
Choosing a Managed Provider Without an SLA and Support
A status page provider is just like any other service provider like your cloud vendor or payment gateway. Before you choose a provider, make sure they have an acceptable SLA. Look at online reviews and past outage reports to get an idea of their reliability.
The ability to reach their support team easily is also important. If the provider has multiple support channels, make sure they are reachable. Add their support contacts to your incident response playbook.
Choosing a Provider That Does Not Have an API
Your uptime monitoring systems will integrate with your status page provider to automatically update the status page about availability trends. If the provider does not have an API, you will have to manually update it. It can quickly become a bottleneck. Manually updating the status page for uptime information is not a good use of your time.
However, during incidents, you will want to post manual updates, as they are based on the results of human investigation. A provider that has APIs as well as a way to manually post incidents is a good choice.
Credibility Mistakes to Avoid
Not Acknowledging Outages
When you become aware of an outage, the first step is to acknowledge it. The outage could be detected either by your own monitoring systems or in the worst case, by your customers. Update the status page to reflect the situation. At the outset, your team might not have all the information, which is fine. Accept the fact and post periodic progress updates as you get more information.
Not Owning Up to Mistakes
Once you have mitigated the outage and systems are up and running, your team will prepare a post-mortem report. The outage could have been caused by an outage in your cloud vendor, or a bug in your code, or other dependencies, or a human error. Accepting mistakes and addressing them publicly is a good way to build credibility and trust.
The Service Recovery Paradox
The Service Recovery Paradox suggests that a company can build greater trust by publicly acknowledging and effectively addressing them. The term was coined in 1992 by Michael A. McCollough and Sundar G. Bharadwaj. They described a situation where, after a failure was addressed satisfactorily, customers expressed greater trust and loyalty than before the failure.
For an example of a detailed post-mortem, see Google Cloud Networking Incident #19009.
Omitting Status Page Updates from Your Incident Management Strategy
Your incident management strategy should include updating your status page. During an incident, your team will be busy investigating the incident and internal communications. It is easy to forget that your customers, and not just the ones reaching out to your support directly, need to be informed. Adopting status page updates as part of your process will ensure that it is done.
Transparency Mistakes to Avoid
Not Publishing Meaningful Post-Mortems
A post-mortem is a detailed analysis of an incident. It lays out the root causes, lessons learned, and recommendations for improvement. Your internal post-mortem report will have a lot of internal information that you might not be able to share. However, it is absolutely necessary to publish a public post-mortem which includes as much detail as possible without revealing sensitive information.
You can post the post-mortem on your status page as a follow-up to the incident. You can also publish it on your blog or social media channels.
Communication Mistakes to Avoid
Being Vague About the Ongoing Status
- "There is an incident and we are looking into it." (We know that already. When will you update us next?)
- "Some of our customers are experiencing issues." (Which systems are affected so that I can check if I am affected too?)
These do not convey much useful information to your customers.
Initially, your team might not be aware of which systems are affected and the impact of the outage. This is totally fine. As your investigation progresses, you can update the status page with more information. The first update you post will not have much concrete information, but you can still say that you will post the next update within a specific period of time.
Stating Vague Timelines
Not so good updates:
- "We are working on it."
- "We will update you as soon as possible."
A better update:
- "We are working on it and we will post the next update in 30 minutes."
After 30 minutes, even if you have not made much progress, post an update. Your customers will appreciate the fact that you are not just working to fix the issue but are also communicating with them.

Screenshot from an incident update.
Not Having an Easy Way To Reach Your Support Team
Your support team might be on one or more of these:
- Helpdesk software
- Chat
- Social Media
- Phone
Link to your support team from your status page, and make sure your support portal is separately hosted or managed by an external provider.
Actionability Mistakes to Avoid
Not Including Workarounds
If your customers are affected by the outage, share any known workarounds or alternatives, if any.

Screenshot from a workaround from Hetzner's status page.
Discoverability Mistakes to Avoid
Leaving Out the Link to Your Status Page From Your Website
Link to your status page from your website and your support portal. Most services will have a link to their status page on their website footer.

Not Linking the Status Page From Your Social Media Channels
Link to your status page from your social media channels. When there is an outage, people might visit your social media outlets like X looking for updates about it. Making it easy to find your status page will also decrease the load on your support team.
Conclusion
A public status page is a crucial part of your organization's public presence. Ensuring it is up and running and that it is managed well is important to your organization's reputation. An updated and reliable status page is one of the key ways to build trust with your users and customers.
Trouble keeping up with dozens of status pages?
Track all your third-party service statuses on a single status page with IncidentHub.
IncidentHub is not affiliated with any of the services and vendors mentioned in this article.
This article first appeared on the IncidentHub blog.