RPC error HTTP 503: Upstream temporarily unavailable

Last updated:

At a glance

Error details
PropertyValue
Applies toEvery network, HTTP and WebSocket
HTTP status503
HeadersX-Triport-Error: upstream_unavailable, X-Triport-Error-Class: platform, Retry-After
JSON-RPC code-32603 on fallback paths; -32000 on BNB Smart Chain
Whose faultThe platform, not your key or plan
RetryableYes, with backoff; check first for a send

Cause

We answer 503 when the upstream for a method fails or refuses us. On fallback paths a provider's own 429 or 401 is deliberately not passed through to you, because you would read it as your own plan limit; the gateway replaces it with a 503 that says what happened, as a JSON-RPC -32603 body with data.class set to platform. On BNB Smart Chain the body is the shorter -32000 upstream unavailable. The exact body varies by network, so branch on the status.

Solution

  1. Honour Retry-After if it is present, otherwise wait a couple of seconds, then retry with exponential backoff and jitter.
  2. Read X-Triport-Error-Class. platform means our side; your key and your request are fine, so do not change them.
  3. Do not resend a transaction you cannot identify. For a send, check the signature or hash first: the transaction may have been delivered before the response failed.
  4. If it lasts more than a few minutes, check the status page and quote the method, network and time when you contact us.

429 or 503?

The two get confused because a provider's refusal often looks like a client limit. Use this table to decide whether to slow down or wait.

429 compared with 503
429 rate_limited503 upstream unavailable
CauseYour RPS on this categoryAn upstream failed or refused
Class headertierplatform
Upgrade helpsYesNo
Right responseSlow down, honour Retry-AfterRetry shortly, then fail over

BNB Smart Chain

BSC is served from public gateways, so the pool has less headroom than networks with dedicated nodes. A deep eth_getLogs that no archive can take gets a separate answer rather than a 503, and that one is worth retrying with a narrower range.

Example

{
  "jsonrpc": "2.0",
  "id": null,
  "error": {
    "code": -32603,
    "message": "The upstream for this method is temporarily unavailable on our side. This is a Triport platform issue, not your plan limit: retry in a few seconds.",
    "data": {
      "error": "upstream_unavailable",
      "class": "platform",
      "retry_after_sec": 2
    }
  }
}

FAQ

Is a 503 my rate limit?
No. Your own limit is always a 429 with limit_rps and category fields. A 503 means the upstream failed, and the response says it is a platform issue.
Should I fail over to another provider on 503?
If availability matters more than cost, yes: retry with backoff first, then fail over. A second provider is reasonable for any production system, ours included.