A status page is a dedicated web page on which a software provider publishes the current operational state of its service, ongoing incidents, their updates and planned maintenance. In SaaS operations, it is the primary channel for incident communication, giving customers one authoritative place to check whether a problem is on their side or the provider’s.
A good status page reduces support ticket volume during outages, supports commitments made in service-level agreements and builds trust through transparent, timely updates. A poor one, slow to change or vague, damages credibility more than the outage itself.
What a status page contains
A status page combines component status, incident history and maintenance notices in one view. The service is broken into components that customers recognize, such as the web application, the API, login, billing or a specific region, and each component shows a status level.
| Element | What it shows | Why it matters |
|---|---|---|
| Overall status banner | One summary state for the whole service | Answers the first question in seconds |
| Component list | Status of each product area or region | Shows scope of a problem |
| Active incidents | Timestamped updates on current problems | Keeps customers informed |
| Scheduled maintenance | Planned work with start and end times | Lets customers plan around it |
| Incident history | Past incidents, often 90 days or more | Demonstrates reliability over time |
| Uptime figures | Availability per component over a period | Supports SLA discussions |
| Subscription options | Email, SMS, webhook or feed alerts | Pushes updates instead of polling |
The page should be hosted on infrastructure independent of the main service, often a separate provider and domain, so that it stays available when the product itself is down.
Status levels and incident updates
Status pages use a small, fixed vocabulary of severity levels so that customers can interpret them consistently. The exact labels vary, but most follow a scale similar to the one below.
| Status level | Meaning | Typical customer impact |
|---|---|---|
| Operational | Working normally | None |
| Degraded performance | Slower than normal or intermittent errors | Tasks take longer |
| Partial outage | Some users or functions unavailable | Some work blocked |
| Major outage | Component unavailable for most users | Work stopped |
| Under maintenance | Planned work in progress | Expected and announced |
Incidents move through stages such as investigating, identified, monitoring and resolved. A widely used practice is to post the first acknowledgment within minutes of detection and to update at a fixed cadence, often every 30 to 60 minutes, even when there is no new information. A silent page during an outage is interpreted as neglect.
After resolution, many providers publish a post-incident review that explains the cause, the impact window and the corrective actions. This closes the loop and turns an outage into evidence of mature operations.
Public, private and automated status pages
Status pages differ in audience and in how status is set. The right model depends on the customer base, the sensitivity of incident details and the maturity of monitoring.
| Variant | Audience | Strength | Weakness |
|---|---|---|---|
| Public page | Anyone | Maximum transparency | Exposes every incident publicly |
| Private or audience-specific page | Logged-in customers or tenants | Tailored, more detail possible | Harder to reach during login outages |
| Internal page | Employees and support staff | Coordinates internal response | Not visible to customers |
| Manually updated | Any | Human judgment in messaging | Slow to react |
| Monitoring-driven | Any | Fast and objective | False alarms if checks are noisy |
Many teams use a hybrid approach: monitoring can flag a component as degraded automatically, while a human writes the incident text. Fully automatic updates risk publishing false outages; fully manual updates risk long delays.
How a status page fits with neighboring practices
A status page is one piece of a provider’s trust and support infrastructure. It is related to, but distinct from, the trust center, the help center and service credit policies.
| Concept | Main question it answers | Relation to the status page |
|---|---|---|
| Status page | Is the service working right now | Live operational truth |
| Trust center | Is the provider secure and compliant | Static assurance, links to status history |
| Help center | How the product is used | May embed the current status banner |
| Service credit | What compensation applies after downtime | Uses incident and uptime records |
| Support ticket | What is wrong in one account | Volume drops when the page is accurate |
Common mistakes and good practice
The most damaging mistake is a status page that shows all systems operational during a visible outage. Customers notice immediately, and the mismatch undermines every later update. Typical causes are manual processes with no clear owner and components defined too broadly.
- Assign a clear incident communication owner for every on-call rotation.
- Define components from the customer’s point of view, not by internal service names.
- Prepare message templates for each status level so the first post is fast.
- Avoid technical jargon and blame in updates; state impact, workaround and next update time.
- Report uptime figures honestly, including partial outages, rather than only total downtime.
- Announce maintenance several days in advance and confirm when it ends.
Legal and commercial teams should review the wording of uptime metrics, because figures on a status page may be read as evidence in SLA disputes.
The short version
A status page is like the departure board at an airport. Instead of everyone asking the staff whether their flight is delayed, the board shows the current state for all to see, and it changes as soon as something happens.
For an online service, the status page tells customers whether the service is working, which parts are affected by a problem and when the next update will come. The key idea is simple: honest, fast information saves everyone time and keeps trust intact even when something goes wrong.
Where it makes a difference
A project management service with customers in Europe and North America suffers a database failover problem at 09:10 in the morning. Monitoring flags the API as degraded at 09:12, and the on-call engineer posts an investigating notice at 09:15, marking the API and web application as partial outage.
Updates follow every 30 minutes. At 10:05 the team posts that the cause is identified, and at 10:40 the status moves to monitoring. The incident is resolved at 11:05. Support staff link to the status page in every reply, and the number of new tickets during the incident is far lower than in a similar outage the previous year, when no status page existed.
Two days later, the team publishes a post-incident review. Enterprise customers use the recorded impact window of 1 hour 55 minutes to calculate their service credits without a dispute.