--- title: "Building Trust with Status Pages" url: "https://www.openstatus.dev/docs/concept/best-practices-status-page" date: "2018-10-20" author: "openstatus" description: "Understanding how to communicate effectively during incidents and build user trust through transparency." category: "Concepts" --- ``` +------------------------------------------------+ | openstatus status page | +------------------------------------------------+ | Service name | Status | Uptime | +-------------------+------------+---------------+ | Web Server | OK | 99.9% | | Database | OK | 99.8% | | API Gateway | Degraded | 99.5% | | Monitoring | OK | 100% | | Payment Processing| OK | 99.7% | +-------------------+------------+---------------+ | Incidents: | | | | - Degraded performance on API Gateway due | | to high traffic. Our team is investigating.| +------------------------------------------------+ ``` ## The purpose of a status page A status page is more than just a dashboard of green lights. It's a critical tool for communication and a cornerstone of building trust with your users. Its primary purpose is to provide a single, authoritative source of truth about your service's health and any ongoing incidents. When done right, a status page: - **Reduces support burden**: Users can self-serve information about outages instead of contacting your team. - **Builds trust**: Proactive transparency, even when things go wrong, demonstrates accountability. - **Improves communication**: It provides a central and consistent channel for incident updates. - **Demonstrates professionalism**: It shows that you take reliability and user experience seriously. This article explores the principles that make a status page an effective tool for building trust. ## Principles of effective status pages ### Maintain transparency and honesty A status page's effectiveness hinges on being a reliable source of truth. Be upfront about issues, even minor ones. Hiding problems erodes user trust and can lead to frustration and a higher support load. - **Communicate clearly** — use simple, non-technical language. Your users shouldn't need a technical dictionary to understand the impact of an issue. - **Be timely** — update the page as soon as an incident is confirmed. Provide regular, predictable updates throughout the resolution process, even if the only update is "we're still working on it." ### Automate where possible Manual updates during a high-stress outage are prone to error and can be slow. Automation ensures that your status page reflects reality quickly and accurately. - **Integrate monitoring tools** — your status page should be directly connected to your internal monitoring and alerting systems. When a metric crosses a threshold (e.g., a high error rate), the status page can be updated automatically to reflect a degraded state. - **Use an API** — we provide APIs that let you programmatically update component statuses and post new incidents, integrating your status page into your incident response workflows. ### Provide context-rich incident communication When an incident occurs, a structured narrative helps users understand the situation. - **Start with the impact** — clearly and concisely state what the problem is from the user's perspective. For example, "Users are currently unable to log in." - **Explain the cause (when known)** — briefly explain the root cause if you've identified it. Transparency here is key. - **Outline next steps and ETA** — explain what is being done to resolve the issue and provide an estimated time to resolution if possible. It's better to give a conservative estimate or no estimate than to give one you can't meet. A typical incident communication lifecycle looks like this: - **Investigating** — "We're currently investigating an issue affecting user logins." - **Identified** — "We've identified the root cause as a database connection issue and are working on a fix." - **Monitoring** — "A fix has been deployed, and we're monitoring the system to ensure stability." - **Resolved** — "The issue has been resolved. We will publish a post-mortem within 48 hours." ### Ensure easy accessibility Your status page is useless if no one can find it. - **Prominent link** — link to your status page from your application's footer, your main website, and your support documentation. - **Custom domain** — use a simple, memorable URL like `status.yourcompany.com`. ## Advanced considerations for deeper trust ### Scheduled maintenance Communicating planned downtime is just as important as communicating unexpected incidents. - Announce maintenance well in advance (e.g., at least 72 hours). - Display upcoming maintenance windows clearly on the status page. - Send reminders to subscribers before maintenance begins. ### Historical data and post-mortems Demonstrate your commitment to reliability by being open about your track record. - Display historical uptime percentages (e.g., over the last 30/60/90 days). - Link to past incidents and their post-mortems. Being honest about past failures and what you've learned from them is a powerful trust-builder. ### Subscriber notifications Allow users to opt-in to the level of communication they want. - Email notifications for new incidents and resolutions. - SMS for critical alerts (if applicable). - RSS/Atom feeds for users who want to integrate your status into their own monitoring. ## Common pitfalls to avoid 1. **Claiming unrealistic uptime** — don't claim 100% uptime unless you can back it up. Honesty is better than perfection. 2. **Hiding or downplaying incidents** — users will find out anyway. It's better they hear it from you. 3. **Using technical jargon** — write for a broad audience, not just other engineers. 4. **Leaving users in the dark** — during an incident, regular updates are crucial, even if there's no new information. A simple "still investigating" is better than silence. 5. **Hosting your status page on the same infrastructure** — your status page must be available even when your main service is down. ## Implementing with openstatus - **[Create a status page](/docs/tutorial/create-your-first-status-page)** — get set up in minutes. - **[Configure your page](/docs/guides/how-to-configure-status-page)** — customise its appearance to match your brand. - **[Understand uptime calculations](/docs/concept/uptime-calculation-and-values)** — be transparent about how you measure uptime. ## Next steps - **[Understanding uptime monitoring](/docs/concept/uptime-monitoring)** — learn more about monitoring what you communicate. - **[Status page reference](/docs/reference/status-page)** — dive into technical configuration options.