Status Page Terminology: Partial Outage, Degraded and Major Outage Explained
May 05, 2026 | by openstatus | [reference]
Status pages use a small, shared vocabulary — operational, degraded performance, partial outage, major outage, under maintenance — and almost none of it is defined on the page itself. The result is that the same words mean different things at different companies, and readers guess.
This is the reference for what each status means, and for how to pick the right one while an incident is still running. If you are looking for the broader introduction instead, what a status page is and why you need one covers that.
Status page terminology
Operational
Everything works. The component is responding correctly and within its normal latency range. This is the default state, and it should genuinely mean "no known issues" — marking something operational while you investigate reports is how status pages lose credibility.
Degraded performance
The component works, but not properly. Responses are slow, a subset of requests fail and succeed on retry, or a feature is unavailable while the rest of the component functions.
This is the most under-used status and the most useful one. Most real incidents are degradations, not outages, and reaching for "operational" or "major outage" because degraded feels ambiguous is what makes a status page feel dishonest.
Partial outage
Part of the component is fully unavailable, or the component is unavailable for a subset of users — one region, one plan tier, one integration. Requests to the affected part fail rather than merely slow down.
The distinction from degraded is failure, not slowness. The distinction from a major outage is scope: some users or some functionality still work completely.
Major outage
The component is fully unavailable to essentially all users. Nothing useful is being served.
Use it sparingly and honestly. A major outage on one component does not mean a major outage everywhere — component-level accuracy is the point of having components at all.
Under maintenance
Planned, announced downtime inside a stated window. It reads differently from an outage to anyone looking, which is precisely why scheduled work belongs here rather than showing as an unexplained outage.
Choosing between them during an incident
The practical test, in order: is anything failing outright? If no, and it is merely slow or flaky, that is degraded. If yes, does it affect everyone and everything in that component? If no, that is a partial outage. If yes, that is a major outage. When two statuses both fit, pick the more severe one — under-reporting costs you more trust than over-reporting.
Where these statuses appear
A status page exists to deflect support load during outages, build trust through honest communication, and signal to enterprise buyers that you take reliability seriously. The vocabulary above is how it does that.
What a Status Page Actually Shows
A useful status page has four things:
1. Component Status
A list of the major parts of your service - API, dashboard, authentication, billing, integrations - each with a current state (operational, degraded, partial outage, major outage).
This is the headline. Users scan it in two seconds to answer: "is the part I care about broken?"
2. Active Incidents
When something is wrong, you post an incident with a timestamp, affected components, severity, and a running timeline of updates.
The format matters. Each update should answer: what happened, what we know, what we're doing, when we'll update next. "Investigating" with no follow-up for two hours is worse than no status page at all.
3. Scheduled Maintenance
Planned downtime, announced in advance with a window, affected components, and expected impact. This is how you preserve trust during necessary disruptions - users tolerate maintenance they knew about.
4. Historical Uptime
A rolling view of the last 30, 60, or 90 days showing uptime percentages and past incidents. This is your reliability proof. Enterprise buyers will scroll through it before signing a contract.
Why Companies Use Status Pages
Deflect Support Load
Every outage generates a wave of identical support tickets: "is it down for everyone?" A public status page answers that question without a human in the loop. Big incidents that would have taken a team hours to triage become a single status page update.
Build Trust Through Transparency
Counterintuitively, admitting failures publicly builds trust. Companies that hide outages get caught - users notice, screenshot, and post on social. Companies that own incidents publicly with clear updates and honest postmortems come out stronger. Reliability isn't never failing. It's failing well.
Meet Enterprise Requirements
Enterprise buyers often require a public status page before signing. It's table stakes for B2B SaaS above a certain deal size. No status page, no contract.
Coordinate Internal Response
A status page is also a forcing function for incident response. The act of writing a public update clarifies what you actually know, what you're doing, and what's still uncertain. It's a discipline as much as a communication channel.
Public vs Private Status Pages
Public pages are for customers. They're curated, lag slightly behind real-time, and focus on user-impacting events. The audience is non-technical. Updates are written in plain language.
Private pages are for internal teams or specific partners. They're real-time, granular, and often include metrics that would confuse public users (per-region latency, error budget burn rate, SLO compliance). The audience is engineers and operations.
Most mature SaaS companies run both. Public for trust, private for operations. See our guide on public vs private status pages for the deeper tradeoffs.
What Makes a Good Status Page
Hosted Independently
Put it on a separate domain (status.yourcompany.com) on infrastructure that doesn't share fate with your main service. If your status page goes down with your service, it's worse than not having one - users assume the whole company is offline.
Honest in Real Time
A status page that shows "all systems operational" during an obvious outage destroys trust faster than no status page at all. Better to say nothing than to lie. Better to say "investigating reports of issues" than to wait for full diagnosis.
Subscribable
Users should be able to subscribe to updates via email, SMS, Slack, RSS, or webhook. Polling the page is not a workflow. The whole point is that updates push to users.
Searchable Historical Record
Past incidents stay accessible. Postmortems get linked from incident pages. Uptime metrics are computable and visible. This is how the status page doubles as a long-term reliability signal.
Common Mistakes
Only updating once an incident is resolved. Users want updates during the incident. Resolved-after-the-fact is documentation, not communication.
Vague status definitions. What's the difference between "degraded" and "partial outage" on your page? If your team doesn't know, neither do your users. Define them and stick to it.
Painting things green. A status page that's always 100% green when users are experiencing problems isn't a status page - it's a marketing brochure. Tune your monitoring to actually surface user impact.
No subscription options. Forcing users to refresh manually means they don't get updates. They get frustrated and tweet at you instead.
How Status Pages Connect to Monitoring
A status page is a communication layer. The data behind it comes from your uptime monitoring and synthetic monitoring systems.
The pipeline:
- Monitors detect a problem
- Alerts wake up on-call engineers
- Engineers triage and update the status page
- Users see the update and stop filing duplicate tickets
Some teams automate step 3 for low-severity events. Most keep a human in the loop for anything customer-visible - automated status updates that fire on flaky monitors create more noise than they prevent.
The Bottom Line
A status page is the simplest, highest-leverage trust-building tool you have during incidents. It deflects support load, signals maturity, and forces you to communicate clearly when things break.
If you don't have one, you're either too small to need one (rare) or losing trust during every outage without realizing it (common).
If you are ready to run one, a hosted status page gives you components, incident history, maintenance windows and subscriber notifications on your own domain without building any of it yourself.
Frequently asked questions
What does partial outage mean on a status page?
A partial outage means part of a component is fully unavailable, or the component is unavailable for a subset of users — one region, one plan tier, or one integration. Requests to the affected part fail outright rather than merely running slowly. It sits between degraded performance, where things still work but badly, and a major outage, where nothing works for anyone.
What is the difference between degraded performance and a partial outage?
Degraded performance means the component still works but not properly — slow responses, intermittent failures that succeed on retry, or one feature unavailable while the rest functions. A partial outage means something is failing outright, just not for everyone or not across the whole component. The test is failure versus slowness.
What does major outage mean?
A major outage means the component is fully unavailable to essentially all users and nothing useful is being served. It is scoped to the component, not the whole service — a major outage on billing does not imply a major outage on your API, which is the reason to break a status page into components in the first place.
What does operational mean on a status page?
Operational means the component is responding correctly and within its normal latency range, with no known issues. It is the default state. Leaving something marked operational while you actively investigate user reports is the fastest way to make a status page untrustworthy — move it to degraded performance while you look.
Which status should I use during an incident?
Work through it in order. Is anything failing outright? If not, and it is only slow or flaky, use degraded performance. If something is failing, does it affect every user and all functionality in that component? If not, use partial outage. If so, use major outage. When two statuses both fit, choose the more severe — under-reporting costs more trust than over-reporting.
OpenStatus is an open-source status page and monitoring platform. Set up a public status page, configure monitors, and start communicating reliably during incidents - all from one place.
Try openstatus freeStart free. No credit card required. Set up your first status page in under 5 minutes.