RPC 429 errors: causes and fixes

HTTP 429 means a request has been rate limited. The response may include Retry-After to indicate when to try again. The status alone does not tell you which quota or capacity boundary was reached.

Common causes include bursts, too many concurrent calls, method-specific limits, shared public-endpoint capacity, and retries after earlier failures. Heavy traces and log scans can hit a different boundary from ordinary reads. Providers may also represent throttling as a JSON-RPC error, so inspect the response body as well as HTTP status.

Distinguish customer limits from upstream capacity:

• Customer account, key, or plan limit: the application must reduce demand, wait for the applicable reset, or arrange more capacity. An additional internal upstream does not increase that allowance.
• Upstream throttling within a managed route: routing, capacity, and recovery are the RPC operator’s responsibility.
• Request shape or method limit: adjust the request or confirm supported capability. A smaller log range can help a response-size problem but does not fix an exhausted account allowance.

Quota exhaustion does not always use HTTP 429. Follow the documented error and reset behavior for the endpoint rather than treating every refusal as the same failure.

Many systems respond to 429s by retrying immediately. That can create a loop:

1. Provider starts rate limiting.
2. Application retries failed requests.
3. Request volume increases.
4. Provider rate limits more.
5. Backlog grows.
6. The system falls further behind.

For indexers and data pipelines, this can turn a temporary provider limit into a sustained failure.

Collect enough evidence to identify the limit before changing the architecture:

• affected chains and methods
• HTTP status, JSON-RPC error, and Retry-After if present
• request rate, burst size, and concurrency across all workers sharing the account
• original calls versus retry attempts
• eth_getLogs ranges and response sizes
• current quota and the endpoint’s documented limits
• time of occurrence and application impact

First compare demand with the agreed allowance. If the workload stays within that envelope and failures persist, raise the evidence with the managed RPC operator. For SolidRPC, this is a service investigation; your team does not need to identify or route around individual internal providers. Keep API keys and other credentials out of diagnostic exports.

1. Honor the retry delay

Respect Retry-After when present. Otherwise use bounded exponential backoff with jitter. Keep one total deadline and stop retrying when the result is no longer useful. An exhausted allowance may require waiting for its reset or changing capacity, not another immediate attempt.

2. Pace requests across workers

Limit both request rate and concurrency. Several individually modest workers can exceed a shared account limit together. Count each method in a batch according to the endpoint’s rules; one HTTP POST does not necessarily consume one rate-limit token.

3. Separate live and backfill budgets

Give live sync, backfills, and user-facing requests separate queues and concurrency budgets. This isolates application demand without requiring a different provider for each workload.

4. Adapt log ranges to the failure

Narrow dense eth_getLogs ranges when response size or execution time is the problem. For rate throttling, reduce the rate of requests first: splitting one range into many immediate calls can make it worse. See the backfill guide.

5. Cache and retry only useful work

Cache stable historical responses where safe. Avoid repeating successful batch entries or retracing the same transaction unnecessarily. Preserve block identity and reorg handling for data near the head.

6. Assign fallback ownership

If you operate your own provider pool, you also own capability checks, routing, monitoring, and incident recovery. With SolidRPC, upstream selection and failover belong to the service. Application retries stay on one integration; a persistent service failure goes to SolidRPC for investigation.

7. Match capacity to the real workload

Measure sustained demand, bursts, backfills, and recovery traffic before choosing capacity. When legitimate demand exceeds the agreed allowance, reduce or schedule that work or arrange a suitable plan. Managed routing does not make capacity unlimited.

SolidRPC replaces the multi-provider RPC stack your engineers would otherwise operate. One integration covers supported standard, archive, logs, and trace/debug workloads, while SolidRPC owns upstream routing, failover, monitoring, node operations, and recovery.

The benefit is less operational work: your team does not maintain backup-provider integrations or routing runbooks every time upstream capacity changes. It can focus on application demand, useful completions, and product behavior.

SolidRPC still has documented rate limits and plan quotas. Customer-facing throttling can occur when demand exceeds an allowance, and managed failover is not a promise that every request succeeds. Confirm the exact chain and method in the network catalog, then test the normal workload, peak traffic, and backfill recovery through the same integration.

If your current response to 429s is to add another provider, bring the existing providers, routing setup, method mix, and incident workload to a stack review. Compare the operational system you maintain today with the service SolidRPC takes responsibility for.

Identify the limit, pace demand, and keep retries bounded. When the problem is upstream capacity or recovery, the RPC operator should own the response. SolidRPC provides that operational ownership behind one integration, while your team keeps control of its application workload.

Qualify the service against your requirements, migrate in stages, and retire the old provider router once the replacement has passed the agreed checks.