RPC Rate Limits: Diagnosing 429 Errors and Choosing Dedicated Capacity
Diagnose RPC rate limits, HTTP 429 errors, compute quotas and traffic bursts. Learn safe retry patterns and when dedicated node capacity makes sense.
A rate-limit error needs a specific diagnosis
An RPC rate limit restricts the volume of work a service accepts over a period of time. HTTP services commonly signal throttling with 429 Too Many Requests. Some blockchain providers return a JSON-RPC error inside an HTTP 200 response instead. A disconnected WebSocket may require further investigation: throttling is only one possible cause.
Record the HTTP status, RPC error code, method and request timing before changing your infrastructure. A rejected historical query might exceed a block-range cap rather than a requests-per-second limit. Retrying the same oversized query will not fix it.
Request counts do not describe every limit
Shared RPC plans can meter requests, weighted compute units, monthly credits or concurrent calls. Providers may also restrict response sizes, log-query ranges, WebSocket connections and subscriptions. These controls affect applications differently.
A lightweight eth_blockNumber request and a historical trace are both RPC calls, but they can require very different amounts of work. JSON-RPC batching can reduce network round trips without reducing the number of billable operations. Check how your provider counts the methods you use, including calls inside a batch.
Measure bursts, not just averages
Consider a job that sends 600 requests at the beginning of each minute, then stays idle. Its average is only 10 requests per second. Under a strict 50-request one-second window with no burst allowance, 550 of those requests would be rejected. A token-bucket policy could behave differently.
The same pattern appears when workers restart together, an indexer resumes a queue, or many dashboards refresh at once. Measure short-window traffic and concurrency alongside minute-level averages. Separate original requests from retries so that retry traffic does not hide the initial cause.
Retry without creating another burst
For retryable read requests, use bounded exponential backoff with jitter. Respect a valid Retry-After value when one is supplied. If the requested wait exceeds the job's time budget, stop or defer the job instead of retrying early.
Limit attempts per request and retries across the service. Give individual calls a timeout as well: a retry budget cannot help if one attempt waits indefinitely. Inspect the JSON-RPC body after receiving the response. Invalid parameters and unsupported methods need a corrected request, not another attempt.
Keep transaction submission out of a generic read-retry loop. A timeout can happen after a node has accepted a signed transaction. Check its hash and chain status before rebroadcasting, and do not automatically sign a replacement transaction.
Reduce unnecessary work
Use one shared poller when several application components need the same latest-block information. Cache historical results against an explicit block identity, with finality and reorganizations accounted for. Avoid treating current balances or contract metadata as permanently immutable.
For backfills, use bounded block ranges and durable checkpoints. Reduce the range when responses become too large, and adjust concurrency against completed work rather than requests sent. Spread scheduled jobs over time. After each change, measure whether the indexer catches up faster, not merely whether the error count falls.
When dedicated RPC makes sense
Dedicated capacity is worth evaluating when legitimate traffic repeatedly exceeds a shared plan, expensive methods dominate its costs, or backfills cannot finish within your recovery window. Compare the real method mix and required history, not just the advertised requests-per-second figure.
DTEAM does not impose artificial request-rate limits or usage quotas on dedicated nodes. That removes a provider-imposed allowance; it does not remove hardware constraints. CPU, storage, memory, network capacity and client behavior still determine how much useful work the node can complete.
Send DTEAM your chains, method mix and peak traffic, together with representative errors and historical-data requirements. We can scope a dedicated node around the workload, including networks not currently listed on our site.