> ## Documentation Index
> Fetch the complete documentation index at: https://docs.get-exo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Service degraded

> A dependency Exo needs is temporarily unavailable. The request is safe to retry.

This page is the resolution target of the RFC 9457 `type` URI on every `service_degraded` problem body: `https://docs.get-exo.com/errors/service_degraded`.

**HTTP status: `503` Service Unavailable**.

```json theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
{
  "type": "https://docs.get-exo.com/errors/service_degraded",
  "title": "Service degraded",
  "status": 503,
  "detail": "The subject store is temporarily unavailable. Retry shortly.",
  "code": "service_degraded",
  "requestId": "req_9f2c41ab7d0e5c18",
  "suggestedAction": "Retry the request with the same subject selector."
}
```

## Why it happens

The API never returns 500 for a dependency failure. When the token verifier, the subject store, the idempotency store or the webhook store cannot be reached, the request fails as 503 so a client can tell 'retry this' apart from 'fix your request'.

A 503 on webhook registration has one non-transient cause worth knowing: a deployment with no webhook signing key configured refuses registration rather than storing a secret it cannot protect.

## How to fix it

* Retry with exponential backoff. The request did not partially apply.
* If the call carried an `Idempotency-Key`, reuse the same key on the retry. That is what the key is for.
* If 503s persist on one family rather than all of them, quote the `requestId` and the route when you report it.

## Related

* [`rate_limit_exceeded`](/errors/rate_limit_exceeded)
* [Errors](/platform/errors) for the envelope and the full catalogue