{"version":"2.1.277","anchor":"relay-now-respects-retry-after-on-busy-503s-instead-of-treat","canonical_anchor":"relay-now-respects-retry-after-on-busy-503s-instead-of-treat","heading":"Relay now respects Retry-After on busy 503s instead of treating them as hard errors","tier":"notice","area":"Artifact Publish","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/relay-now-respects-retry-after-on-busy-503s-instead-of-treat","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Relay now respects Retry-After on busy 503s instead of treating them as hard errors\n\nBusy 503 responses from the relay now trigger a retry after the server's suggested delay instead of failing outright\n\n**What**\n\nWhen a request to the artifact-frame relay gets back an HTTP 503 (\"service busy\") response, Claude Code now checks for a `Retry-After` header telling it how long to wait. If that header is present, the request is routed back through the relay with that delay applied, and a new telemetry event called `relay_busy` is logged. Previously, this kind of 503 was simply treated as a relay error and not retried.\n\n**Why**\n\nThis lets Claude Code recover automatically from a temporarily busy relay instead of surfacing it as a hard failure.\n\n- Area: Artifact Publish\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}