# 529 Site Is Overloaded (SSL Labs and Anthropic)

> 529 is a non-standard overload code used by SSL Labs and Anthropic. Identify the API, inspect overloaded_error, and back off without confusing it with 429.

Source: https://howhttpworks.com/status-codes/529
Last reviewed: 2026-10-05

> **TL;DR:** 529 means the service itself is overloaded. It isn't a standard HTTP code; Qualys SSL Labs and Anthropic both use it, and Anthropic pairs it with `overloaded_error`. It's not your rate limit (that's `429`), so raising your quota won't fix it. Find out which API returned it, then back off with randomized, capped retries.

## What it means

"Site Is Overloaded" is a common descriptive label, not a standard reason phrase. The [SSL Labs API v4 documentation](https://github.com/ssllabs/ssllabs-scan/blob/master/ssllabs-api-docs-v4.md) uses 529 when the service as a whole is overloaded. If you're the one sending too many assessments, you get [429](https://howhttpworks.com/status-codes/429) instead.

[Anthropic's error documentation](https://docs.anthropic.com/en/api/errors) defines 529 `overloaded_error` as the API being temporarily overloaded. It keeps that separate from the rate and acceleration limits on your own organization: a 529 reflects traffic across all users. Nothing in Anthropic's docs suggests a higher quota helps with it.

## Confirm the API and error

Note the destination URL, the status and the response body. For Anthropic, branch on `error.type`, not on the wording of `error.message`. The body looks like this (an example, not a captured response):

```json
{
  "type": "error",
  "error": {
    "type": "overloaded_error",
    "message": "Overloaded"
  },
  "request_id": "req_example"
}
```

Save the real `request-id` response header for support; Anthropic also documents the matching `request_id` field in the body. You don't need to log credentials or prompt content to identify an overload, so leave them out of your logs.

For SSL Labs, make sure the 529 came from the assessment API itself and not from the site you're assessing. An overloaded API tells you nothing about the TLS setup on your hostname.

## Retry without a request storm

Retry after a delay, with jitter and a cap on attempts. Hold off on new requests while you wait, and decide in advance when to give up and show the caller the failure.

SSL Labs recommends waiting several minutes, but its v4 document gives two different example delays: the table says about 15 minutes, while the prose suggests 30 minutes for 529. Read both as rough guidance, not a promise of when the service recovers. Randomize the wait, as the vendor recommends.

For Anthropic, check your SDK's retry settings before writing your own retry loop. Honor any [Retry-After](https://howhttpworks.com/headers/retry-after) value you receive, and make sure the SDK and your application aren't both retrying, which multiplies the load.

## Streaming needs its own error path

Anthropic documents that errors can arrive mid-stream, after the SSE response has already returned HTTP 200. Handle the stream's error event as well as non-2xx initial responses. If you only check the status code, an overload partway through looks like a finished answer. Mark any partial output as incomplete and decide deliberately whether to retry the whole request.

## Related

- [429 Too Many Requests](https://howhttpworks.com/status-codes/429)
- [503 Service Unavailable](https://howhttpworks.com/status-codes/503)
- [Retry-After](https://howhttpworks.com/headers/retry-after)