< HTTP/1.1 529 Site Is Overloaded

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 uses 529 when the service as a whole is overloaded. If you’re the one sending too many assessments, you get 429 instead.

Anthropic’s error documentation 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):

{
  "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 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
• 503 Service Unavailable
• Retry-After