Imagine millions of people opening a streaming app to watch the final minutes of a championship game.
The live stream is the reason they are there. Recommendations, personalized home-page rows, viewing-history updates and high-resolution thumbnails all improve the experience, but none of them matters as much as keeping the match playing.
Now suppose the recommendation service begins failing under load.
One design allows those failures to propagate into the home page until viewers can no longer reach the stream.
Another temporarily removes personalized recommendations, serves a simpler home page and directs available capacity toward playback. Some users notice that the experience is less polished, but they can still watch the event they came for.
The second application has degraded gracefully.
Graceful degradation is the deliberate ability of an application to continue providing its most important functionality when part of the system is failing, unavailable or under too much pressure—even if that means temporarily providing a simpler, slower or less complete experience.
Google Cloud's Well-Architected Framework describes graceful degradation in similar terms: under high load, a system may continue operating with reduced performance or accuracy rather than failing completely, returning to full functionality once conditions improve. Google Cloud: Design for Graceful Degradation
For Levelworks, graceful degradation is an important part of Resilient App Health. A resilient application should understand which parts of the product are essential, which are optional and what acceptable reduced operation looks like before a failure forces that decision.
Engineering teams sometimes approach graceful degradation as though it were simply another infrastructure pattern.
It is not.
Before deciding how an application should degrade, the team needs to know what absolutely must keep working.
For an ecommerce application, that might be:
A recommendation engine, recently viewed list or personalization layer may be valuable without being essential.
For an enterprise SaaS application, creating and retrieving core business records may matter more than analytics dashboards or scheduled exports.
AWS's reliability guidance describes graceful degradation as converting appropriate hard dependencies into soft dependencies. If a dependency becomes unhealthy, the calling component should continue performing its core function where possible, perhaps using stale data, alternative data or no optional data at all. AWS Well-Architected: Implement Graceful Degradation
That means the first design question is not:
How do we build a fallback?
It is:
What is the central business value this workflow must continue providing?
Without that answer, teams can spend considerable engineering effort keeping low-value features alive while allowing the critical user journey to collapse.
[Internal Link: “What Makes an Application Resilient?”]
Consider a product page assembled from several services:
Product details
Price
Inventory
Reviews
Recommendations
Recently viewed
If recommendations fail, the product can probably still be sold.
If pricing fails, the situation is different.
A graceful design treats those dependencies according to their importance.
The response might become:
Product details ✓
Price ✓
Inventory ✓
Reviews ✓
Recommendations unavailable
Recently viewed unavailable
rather than:
500 Internal Server Error
AWS specifically warns against returning no useful result when one of several dependencies is unavailable and partial results could still be delivered.
This is one of the central ideas behind graceful degradation:
Local failure should produce local loss of functionality wherever the business process allows it.
The alternative is turning every dependency into a requirement for the entire workflow.
The two concepts overlap, but they solve slightly different problems.
Fault tolerance tries to keep functionality operating despite component failure, often through redundancy or failover.
If one application instance dies and another handles its traffic without users noticing, the service has tolerated the fault.
Graceful degradation accepts that some functionality may temporarily disappear.
If the recommendation service fails and the application deliberately removes recommendations while preserving checkout, the product is operating in a degraded mode.
Situation
Typical response
One application instance fails
Another instance takes over
Recommendation service fails
Product page loads without recommendations
Image-processing service overloaded
Lower-quality or delayed images
Analytics system unavailable
Core transactions continue; reporting delayed
Search infrastructure under extreme load
Reduced result depth or optional features disabled
A well-designed application may use both approaches. Some failures should be hidden entirely through fault tolerance, while others are better handled by losing non-essential functionality in a controlled way.
[Internal Link: “Fault Tolerance Explained: How Apps Keep Working When Something Fails”]
Poor degradation usually happens accidentally.
A dependency times out, the front end receives an unexpected response and the user sees a blank area, an infinite spinner or an application error.
Graceful degradation is different because the reduced experience is intentional.
For an important dependency, define:
A product search service, for example, might normally provide highly personalized ranked results.
During degradation, the application might serve a less personalized but still useful result set.
Google SRE describes this principle in its guidance for overloaded production services: systems should provide reasonable but suboptimal results under overload rather than simply failing. Its example notes that Google Search can reduce the amount of work performed and disable optional functionality in order to continue returning useful search results. Google SRE: Production Services Best Practices
Graceful degradation therefore requires deliberately defining acceptable imperfection.
One useful degradation strategy is serving the last known acceptable value when the live source is temporarily unavailable.
Imagine an application showing a store's opening hours.
If the configuration service cannot be reached for thirty seconds, removing the opening hours entirely may be less useful than showing the most recently cached value.
AWS explicitly identifies stale or alternate data as possible degraded responses when a dependency becomes unavailable.
This approach works only when stale information is safe.
A cached article recommendation may be harmless.
A stale inventory quantity may cause overselling.
A stale account balance could be much more serious.
The decision should therefore consider:
Graceful degradation should preserve usefulness without quietly compromising correctness.
Not every function needs to complete immediately.
Suppose a user creates an account successfully, but the analytics platform is unavailable.
Account creation should probably not fail because an optional analytics event could not be delivered.
The application can record the event for later processing or temporarily omit it, depending on the business requirement.
Similar decisions may apply to:
This turns an optional synchronous dependency into work that can wait.
The important distinction is between:
work that must happen now for the business operation to be valid
and
work that can happen later without harming the user or corrupting the process.
Graceful degradation becomes much easier once teams stop putting both categories on the same critical path.
Failure is not the only reason to reduce functionality.
Extreme demand can make graceful degradation valuable even when every component is technically operational.
Suppose an application approaches its safe capacity limit.
Continuing to perform every expensive optional function may push it into complete overload.
Microsoft's throttling guidance specifically describes graceful feature degradation as a strategy where less important features are reduced or disabled so that important functionality retains enough resources. It gives the example of lowering video-streaming resolution when resources become constrained. Microsoft Azure: Throttling Pattern
This can be a sensible trade:
Google SRE similarly recommends graceful load shedding once systems approach overload, because protecting important work can be preferable to allowing excessive demand to cause broader failure. Google SRE: Managing Load
The goal is not simply to reject work.
It is to preserve the most valuable work.
Some degradation can remain invisible.
If recommendations quietly disappear for a minute, users may not need an explanation.
Other changes should be communicated.
Imagine a document-management application temporarily entering read-only mode because its write path is unavailable.
Showing normal edit controls that repeatedly fail creates confusion.
A better degraded experience might state clearly:
Documents can currently be viewed, but editing is temporarily unavailable.
Microsoft's Well-Architected guidance recommends treating graceful degradation as a defined workflow and communicating degraded functionality to users when the change affects their experience. Microsoft Azure: Self-Healing and Self-Preservation
Good degradation communicates the state without overwhelming the user with infrastructure detail.
They do not need to know that "Service B cannot reach Redis cluster C."
They need to know what they can do, what they cannot currently do and whether they need to take any action.
Graceful degradation is not appropriate everywhere.
Imagine a financial application cannot verify the current balance required for a transfer.
Approximating that balance from an old cached value might keep the interface responsive, but it could create a much worse business problem.
Similarly, a healthcare workflow, permissions check or safety-critical operation may need to fail closed instead of returning partial behaviour.
A useful decision test is:
Question
Why it matters
Can this feature disappear temporarily?
Determines whether degradation is acceptable
Can stale data be used safely?
Protects correctness
Can work be delayed?
Identifies asynchronous fallback opportunities
Can partial results still help the user?
Avoids unnecessary total failure
Could degraded behaviour cause financial, security or compliance harm?
Identifies cases where failing may be safer
Will the user understand what changed?
Prevents damaging ambiguity
Graceful degradation should never become an excuse for returning incorrect results simply to keep the screen populated.
Sometimes a degraded mode needs to be activated quickly during an incident.
A high-cost recommendation feature might be consuming excessive database capacity. A problematic export process may threaten the rest of the application. An integration may be failing in a way that creates repeated expensive calls.
Well-designed applications can include controlled mechanisms to disable or alter non-critical behaviour.
AWS describes these as emergency levers: known and tested mechanisms that can disable, throttle or change the behaviour of components so critical functionality can remain available during abnormal conditions. AWS Well-Architected: Implement Emergency Levers
These mechanisms might include feature flags or operational controls, but they need discipline.
An emergency control should have:
A switch that nobody has tested is not an emergency control. It is another uncertainty during an incident.
Degradation should normally be temporary.
Once the failing dependency or overload condition clears, the application needs a controlled way to resume normal behaviour.
Immediately restoring all optional functionality at once can be risky.
Imagine traffic has been throttled during overload. Capacity begins recovering, so every disabled feature is re-enabled simultaneously. Expensive background jobs restart, recommendation calculations return, queued work drains and the system falls back into overload.
Restoration may therefore need to happen progressively.
Useful questions include:
Graceful degradation is only complete when the application has both a safe way down and a safe way back up.
A degraded application is still available, which makes it easy for the condition to escape attention.
Teams should be able to see:
Otherwise a temporary fallback can quietly become normal operation.
This is where Observable supports Resilient App Health.
If the application has been serving cached data for three days because a dependency never recovered, "the page still works" is not enough information.
Degraded operation should be visible as an explicit system state.
A fallback that exists only in code has not yet proved its value.
Test what happens when:
Check both technical and user behaviour.
Does the important workflow still complete?
Does the page remain understandable?
Does the application accidentally expose stale data that should not be used?
Does monitoring show that degradation is active?
Can full functionality return cleanly?
Graceful degradation often fails in the details because teams test only the healthy application.
[Internal Link: “How to Design an App That Recovers Gracefully From Failure”]
For each important user journey, map its dependencies and classify them.
Dependency
If unavailable
Acceptable degraded behaviour
Core transaction database
Core workflow cannot safely continue
Fail safely
Recommendation engine
Personalization disappears
Show generic content
Analytics service
User transaction unaffected
Delay analytics event
Image transformation
Optimized image unavailable
Serve original/lower-quality image
Reporting engine
Reports cannot refresh
Show last successful report with timestamp
Notification provider
Notification delayed
Queue for later
High-cost optional feature during overload
Resource pressure increases
Temporarily disable feature
The exact answers will differ by application.
The value is in deciding them deliberately rather than discovering them during an outage.
The strongest graceful-degradation designs begin with a simple question:
What must still work for this application to remain useful?
Once that is clear, supporting features can be treated differently from business-critical ones.
Optional dependencies can return cached or simpler data. Non-urgent work can wait. Expensive functionality can be reduced under pressure, while users can be told clearly when meaningful capabilities are temporarily unavailable.
For Levelworks, that is why graceful degradation strengthens Resilient App Health. It acknowledges that not every component will be healthy all the time while refusing to let every local problem become a complete product failure.
A good application does not have only two states—perfect and unavailable.
Sometimes the healthiest response to failure is to become temporarily less capable while protecting the functionality that matters most.
