What is service degradation? Meaning and examples

Degradation compared with an outage

A service has more states than "up" and "down". Most teams use a short ladder, and the exact wording differs from one status page to another:

HostTracker status pages show each monitor as operational, degraded, partial outage or under maintenance. The line between degraded and partial outage is a judgment about users. A good rule is that degraded means everyone can still do what they came to do, and partial outage means some people cannot. Write the thresholds down in numbers your team agrees on, for example "response time above 3 seconds for 10 minutes" or "more than 2% of requests failing".

Examples of service degradation

• Slow responses. The home page loads, but it takes eight seconds instead of one.
• A raised error rate. Most requests succeed, but some return 500, 502, 503 or 504 errors. Users see random failures that disappear when they reload.
• One region affected. Visitors in one country or on one internet provider get timeouts while everyone else is fine. The cause is often a CDN node, a routing problem or a DNS issue in that region.
• One feature failing. Search, login or payment stops working while the rest of the site loads.
• Delayed background work. Emails, notifications or exports arrive late.
• Stale or incomplete data. A dashboard lags behind, or cached pages show old prices.
• A reduced mode. The service switches to read-only, hides images or limits search results to protect itself.

What causes service degradation

• Load. Traffic or a batch job pushes servers close to their limits. Queues grow, and response time rises before errors appear.
• A slow dependency. A database, cache, payment provider or API that is slow but not down. Requests wait for it and pile up behind it.
• One bad server. A load balancer with four backends and one failing sends about a quarter of requests to the broken one.
• Exhausted resources. Memory, database connections, disk space or file descriptors run low, or a shared host throttles the CPU.
• Network trouble. Packet loss, a congested link or a routing problem that affects one provider or one region.
• A recent change. A deploy, a configuration edit or a plugin update. Compare the start of the slowdown with your release history first.
• Third-party scripts. A tag manager, chat widget or ad script that loads slowly and delays the page.

Degradation is often the first stage of an outage. A slow database query holds its connections longer. The connection pool fills up, new requests wait for a free connection, and the web server fills with waiting requests. Pages get slower first (degraded), then requests start timing out with 503 or 504 errors (partial outage), and finally nothing gets through (full outage). The same chain can take minutes or hours. If you notice the first stage, you can often add capacity, restart the stuck component or switch off a heavy feature before users lose the service.

Graceful degradation: degrading on purpose

Graceful degradation is a design choice. When a system is overloaded or a dependency fails, it drops the least important work and keeps the core working. Google's Site Reliability Engineering book describes this as serving degraded responses under overload: results that are less accurate or less complete than normal, but cheaper to produce.

Examples: a product page that hides recommendations when the recommendation service is down; a search that scans only part of the data during a traffic peak; an account page that keeps checkout working and shows "order history is temporarily unavailable". Users still get a worse service, so it belongs on the status page. The difference is that the failure was planned for, so the effect is smaller and predictable. A full outage is what remains when there is nothing left to switch off.

How to detect degradation

Degradation is harder to catch than an outage because simple checks can still pass. A page that answers with 200 may take ten seconds or show an error message in its body.

• Measure response time against a threshold, and look at the slowest requests as well as the average. Google's SRE book lists latency, traffic, errors and saturation as the four signals to watch. The guide on TTFB, response time and latency explains what each timing includes.
• Track the error rate over time, not only the last result. One failed check may be noise; three failures in ten checks is a pattern. The recheck strategies guide covers how to confirm a change before alerting.
• Check from several locations and compare. If one region is slow and the others are normal, the problem is local to that path, not the whole service.
• Check content, not only the status code. A content check looks for expected text on the page, which catches a 200 response that shows an error or an empty product list.
• Test complete journeys. A transaction check walks through steps such as sign-in and checkout, so a failing feature shows up even when the home page is fine.
• Add real user data. The synthetic and real user monitoring guide explains why scheduled checks and visitor measurements answer different questions.

Showing degradation on a status page

Mark a component as degraded as soon as you have confirmed that users are affected. Do not wait for the cause. Say what users see, which part is affected, and what they can do meanwhile. Then update on a rhythm you state, even when the update is "no change yet". The status page guide covers the wording.

HostTracker status pages show scheduled maintenance, publish incidents with timestamped updates, and label each monitor as operational, degraded, partial outage or under maintenance. HostTracker checks from 300+ checkpoints in 158 cities and sends alerts by email, SMS, voice call, Slack, Telegram and more. A sensible split is a chat message for degradation that can wait and a phone call or SMS for an outage. To see how one address behaves right now, the HTTP check shows its status code and response time from locations around the world, and the difference between locations is often the first sign of a regional slowdown.

Frequently asked questions

Is service degradation the same as downtime?

No. Downtime means users cannot reach the service. In degradation the service still answers, but with lower speed, lower quality or errors for some requests. A degraded service can become an outage if the cause grows, which is why it is worth fixing early.

What is the difference between degraded performance and a partial outage?

Degraded performance means all features work but are slower or less reliable. A partial outage means some features, regions or users cannot use the service at all.

Does a slow site count against my uptime percentage?

That depends on the definition. A basic uptime figure counts only the time when requests fail or time out. Some service level agreements also count an error rate or a response time above a limit as unavailable. Read the contract text, and see the guides on SLA monitoring and calculating uptime.

What does service degradation mean for an internet connection?

The same idea applies: the connection works, but it is slower than the plan promises, or it has higher latency or packet loss. The ping command on your own device shows latency and packet loss to a server. To measure the other direction, from many places to a server you run, use the ping test.

When does degradation become an incident?

When enough users are affected that someone must act or tell customers. Define this in advance by user impact, not by the technical cause, so that the person on call does not have to decide it at 3 a.m.

Sources and further reading

• Google SRE book: Handling Overload: serving degraded responses and graceful handling of overload.
• Google SRE book: Monitoring Distributed Systems: the four golden signals and how to keep alerts useful.
• Google SRE book: Addressing Cascading Failures: how a slow dependency spreads and how to contain it.