Service Degradation: What It Means and How to Detect It

Service degradation is when a service is still running but no longer performing to its expected level: responses are slow, a share of requests fail, or some features are broken while others work. It sits between fully available and fully down, which is precisely why a check that only asks "did it respond" reports a degraded service as healthy.

Key takeaways

• Degradation is partial failure. The service answers, but slowly, intermittently, or incompletely.
• A binary up/down check will call a degraded service healthy for the entire duration of the event.
• Catch it with thresholds on response-time percentiles and error rate, content checks, and probes from more than one region.
• Average response time hides degradation. Watch p95 and p99, because the average is dominated by the requests that went fine.
• Many SLAs define availability so narrowly that severe degradation counts as uptime. Read the definition before trusting the number.

What service degradation means

Service degradation describes a service that is still up and still serving, but below the level of performance or completeness its users expect. The requests are answered. Some of them are slow, or some of them fail, or some part of what should come back is missing. Nothing is off, which is exactly what makes it hard.

The definition is worth stating precisely because the word is used loosely. Degradation is not a synonym for "an incident", and it is not a polite word for "outage". It names one specific position on a spectrum: the service is neither working properly nor plainly broken. Users notice. Dashboards frequently do not.

That position is what makes degradation expensive out of proportion to its severity. A full outage is unambiguous. Everyone agrees it is happening, the alert fires, the team assembles, and the clock on time to recovery starts. Degradation produces none of that. It generates a slow trickle of support tickets, a handful of engineers each privately wondering whether it is just them, and a status page that says everything is operational because, by the only measure being taken, everything is.

Degradation, outage, disruption, incident

These four terms overlap in everyday use and mean different things in a contract or a postmortem. The distinctions worth holding on to:

The pair that causes the most confusion is degradation and partial outage, and the useful test is whether anything is fully unavailable. If a feature is completely broken while the rest works, that is a partial outage, even if the overall picture looks mild. If everything works but works badly, that is degradation. The distinction matters because they are detected in different ways: a partial outage is visible to a check pointed at the right endpoint, while degradation is only visible to a check that measures something more than availability.

The four shapes degradation takes

Degradation is not one condition, and the four common forms have genuinely different signatures. Knowing which one you are looking at tells you where to look next.

Slow

Everything succeeds and everything takes longer. The classic causes are a database missing an index after a schema change, a cache that has been evicted or has stopped being written to, a downstream dependency that is itself degraded, or simply more load than the current capacity handles gracefully. This is the form most likely to run for hours undetected, because every automated check passes.

Intermittent

A percentage of requests fail while the rest are fine. One unhealthy instance behind a load balancer produces this exactly: if one node in five is returning errors, roughly 20% of users have a broken experience and 80% see nothing wrong. Retries and connection pooling then smear the failure across the user base in a way that makes it hard for any single person to reproduce.

Partial

The page loads and something on it is missing or broken. Search returns nothing, prices fail to load, images 404, a third-party widget hangs and blocks rendering. The HTTP status is 200 throughout. This form is invisible to anything that inspects only the status code, and it is the reason a content check exists.

Regional

The service is healthy from where you are standing and degraded somewhere else. A CDN edge with a stale or broken configuration, a DNS record propagating unevenly, a peering problem between two networks, or a regional cloud incident all produce this. It is the most under-detected form of all, because most teams monitor from wherever their monitoring happens to live, and that is usually near where they built the thing.

Why up/down monitoring reports a degraded service as healthy

This is the core of the problem, and it is structural rather than a matter of tuning. A conventional uptime check makes a request and asks one question: did a response come back without an error status? A degraded service answers that question correctly. The check passes. It will keep passing for the full duration of the event.

Follow the four shapes through such a check and the gap is obvious. A service responding in 14 seconds instead of 2 returns 200, so the check passes. A service failing one request in five passes four checks out of five, and unless the alerting rule is counting failures over a window it will never reach a threshold. A page missing its entire product grid returns 200 with a body the check never reads. And a service degraded only in Singapore stays green forever if the probe runs in Frankfurt.

This is why availability and performance need to be treated as separate measurements rather than one. A service can be 100% available and unusable. The SLA number will look excellent for the month in which it happened.

How to actually detect it

Four signals, in rough order of how much they add relative to the effort of setting them up.

Threshold on response time, and use percentiles

The first and largest improvement is to alert when responses get slow, not only when they stop. It works because slowness precedes most failures rather than following them: a saturated connection pool, a failing disk, an overloaded dependency all show up as latency well before they show up as errors.

Use percentiles rather than the average. An average is dominated by the requests that went fine, so a service where one user in twenty waits 30 seconds can still post a perfectly respectable mean. The response time figures worth watching are p95 and p99, because those describe the experience of the users having the worst time, and those are the users who leave. Set the threshold against your own measured baseline, not an absolute number, and give it a duration so a single slow sample does not page anyone.

Check the content, not just the status code

A status code tells you the server produced a response. It says nothing about whether the response was correct. A check that also looks for an expected string in the body, a product name, a price, an element that only renders when the data layer worked, catches the entire partial-degradation category that status codes miss.

The inverse is just as useful: alert when a string that should never appear does appear. "Something went wrong", "Temporarily unavailable", the framework's own error text. Plenty of applications catch their exceptions, render an apology, and return it with a 200. This is what keyword monitoring is for, and it is the single cheapest defence against the failure mode where the site is technically up and functionally empty.

Check from more than one place

Regional degradation is invisible to a single-location probe by definition. Checking from several regions turns that into a detectable signal, and it does something else useful at the same time: when one location reports a failure and five others do not, you have learned that the problem is on the path rather than at the origin. That distinction is usually the difference between paging your team and opening a ticket with a provider.

It also reduces false alarms in the other direction, since requiring confirmation from a second region before alerting removes most of the noise a single flaky probe generates.

Watch real users as well as synthetic checks

Synthetic checks measure a fixed request from a fixed place on a fixed schedule, which is what makes them comparable over time. Their weakness is that they only ever exercise the paths you thought to configure. Real user monitoring covers the opposite ground: every browser, network and device your users actually have, on every page they actually visit.

For degradation the combination is what pays. Synthetic checks give you the alert and the clean baseline. Real user data tells you how many people it reached, in which countries, on which devices, and whether the degradation your probe measured is the degradation your users experienced. The relationship between the two is covered at length in synthetic monitoring vs real user monitoring.

Is degradation downtime? The contractual answer

Usually not, and that is deliberate on the part of whoever wrote the agreement.

Most service level agreements define availability narrowly, and most define it in terms of errors rather than performance. A common shape is that a service counts as unavailable when its error rate exceeds a stated threshold across a measurement interval of several minutes. Under a definition like that, a service returning correct responses ten times slower than normal is fully available for every minute of the event, and a service failing 4% of requests against a 5% threshold is available too. Neither shows up as a single second of downtime.

The practical consequences are worth being clear about. If you buy a service, read the definition of "unavailable" in the agreement rather than the percentage on the marketing page, because the definition is what determines whether an event you experienced generates a credit. If you sell one, decide whether your commitments should cover performance and not just availability, and be aware that a monthly report of 99.99% is a defensible number and not necessarily an honest description of the month.

This is where internal service level objectives earn their place. An SLO is yours to define, so it can carry a latency target the contract does not, for example that 99% of requests complete within 500 ms. That target turns degradation into something measurable, budgeted and alertable rather than something the numbers are structurally unable to see. The uptime SLA calculator shows how little downtime the familiar percentages actually permit, which is a useful reference point when you are deciding what to promise.

Communicating degradation

Degradation is harder to communicate than an outage, for a reason that is easy to miss: during an outage nobody has to decide whether to post. During degradation somebody does, and the pressure runs towards waiting, because the impact is ambiguous and posting feels like admitting to something that might resolve itself in ten minutes.

Post anyway. Users experiencing a slow or partially broken service will spend their first several minutes assuming the fault is theirs, reloading, clearing caches, checking their own connection, and then contacting support. A status page showing "Degraded performance" ends all of that immediately, and it is the difference between a support queue and a shrug.

Three things make the notice worth reading. Name the affected component rather than the whole product, since "Checkout is slow" is far more useful than "we are investigating an issue". Say what users should expect, including whether their work is at risk or merely slow, which is the question they actually have. And give a time for the next update and then meet it, because an update that says nothing new at the promised time still tells people someone is working on it.

See how Pulsetic's status pages catches this from the outside, across 15+ locations.