Failover that actually fails over
If a node stops answering, your request moves to the next healthy one in the same tier — you get an answer, not a 503. Iteradian builds a ranked list of candidate nodes for every request, ordered by priority and then by current load, and tries up to three of them in turn until one responds. The node that failed is dropped from the cached candidate list immediately, so other requests in flight stop paying the same timeout.
Verified against the gateway request path on .
What happens to a single request
1. Build the candidate list
Every request resolves its network, then collects the nodes that can serve it. The list is filtered by what the plan grants. Shared pool: Free RPC and Developer RPC. Priority pool added: Professional RPC. Nodes reserved for the organization added: Dedicated RPC. A Dedicated RPC organization with no reserved node for a chain falls through to the shared and priority pools rather than failing.
2. Order by priority, then by current load
Candidates are sorted by their configured priority first and their current load second, so the highest-priority node that is not already busy goes first. There is no weighting: the node table carries a weight column, but selection does not read it, and this page will not pretend otherwise.
3. Forward, and fall forward
The gateway sends the request to the first candidate. If that node fails to answer — a timeout, a refused connection, any transport failure — the request moves to the next candidate in the list and tries again, up to three nodes in all. Transaction submissions such as eth_sendRawTransaction are the exception: they go to one node and are never retried or replayed. This is the part that used to be missing: the gateway picked one node and returned a 503 if it was unreachable.
4. Evict the node that failed
A node that fails is dropped from the cached candidate list for its network straight away. Without that, every concurrent request would independently discover the same sick node and pay the same timeout before moving on. Evicting once means the rest of your traffic routes around it immediately.
5. Only then, a 503
If every node it tries fails, the caller gets HTTP 503 with a JSON-RPC 2.0 error body and code -32603. That is several nodes failing in a row, not one unlucky pick, and it is worth retrying with backoff. Either way the attempt is recorded, so the failure appears in your request log and usage rather than vanishing.
Why the eviction matters more than the retry
A retry helps one request. Eviction helps every request behind it. When a node starts timing out, the expensive part is not the first failure — it is the next several hundred requests that each wait out the same timeout before discovering the same thing. Dropping the node from the cached candidate list at the moment of the first failure turns a chain-wide slowdown into a single slow request.
None of this requires anything from your client. The same POST /rpc/v1/{network} call behaves the same way whether it was served first time or on the third candidate. You do not get a redirect, a different response shape, or a status code to special-case.
Failover FAQ
Does Iteradian retry my request on another node?
Yes, on a transport failure. If the node the gateway picked does not answer, the request is forwarded to the next healthy candidate in the same tier, up to three nodes before giving up. Transaction submissions are the exception: they are sent to one node and never retried or replayed, so a transaction is never broadcast twice.
Does a JSON-RPC error trigger a retry?
No. A node that returns a JSON-RPC error has answered — the error is the answer, and re-sending the call to a different node would not change it. Only a failure to get a response at all moves the request onward. The error is recorded against your usage and shows up in the request log.
How are nodes chosen?
By priority first, then by current load, within the pools your plan can reach. The node table has a weight column, but nothing reads it, so selection is not weighted.
Is a failed node taken out of rotation for everyone?
The cached candidate list for that network is invalidated as soon as a node fails, so requests that follow do not queue up behind the same timeout. Longer-term health is tracked separately by periodic health checks, which also feed the failover timeline in your dashboard.
Can I see failovers that affected my traffic?
Yes. The dashboard shows a failover timeline derived from recorded node health checks for the networks you actually sent traffic to, with the number of your own requests in each window. When there is no health data for the period, it shows nothing rather than inventing a history.