RPC rate limit errors stop your app because you sent more requests than your provider allows, and the fastest fix is almost never a bigger plan: batch your calls, cache repeated reads, and add retry logic with backoff before you spend a dollar. This guide shows how to read the error correctly, six fixes ranked from fastest to most durable, and the math for deciding when a paid tier or your own node actually becomes the cheaper option.
Quick solution
If your app is throwing 429 errors right now, do these four things in order:
- Add exponential backoff. Catch the 429 (or JSON-RPC error
-32005), wait 1 second, retry, and double the wait on each failure up to about 30 seconds. Most SDKs, including ethers.js and viem, let you wrap the transport with a retry policy. - Batch your reads. If you request 50 token balances with 50 separate calls, switch to a multicall contract or the provider's batch endpoint. One batched request replaces dozens of single ones.
- Cache anything that repeats. Block numbers, token metadata, and contract state that changes slowly should be served from your own cache, not fetched again on every page load.
- Slow your polling loop. A bot polling every 100 ms makes 864,000 requests a day from that one loop alone. Poll on new blocks instead (about every 12 seconds on Ethereum mainnet).
Those four steps resolve the large majority of throttling problems without touching your billing page. The rest of this guide explains why they work and when they are not enough.
Why providers throttle you
Every RPC provider runs real servers that execute your requests against blockchain state. Some requests are cheap, like asking for the latest block number. Others are expensive, like replaying a complex contract call or scanning months of event logs. Providers protect their infrastructure by metering usage, and they meter it in two different ways at once:
- A rate ceiling — how fast you can send, measured per second.
- A volume ceiling — how much you can send in total, measured per day or per month.
You can hit either one independently. A quiet app that suddenly bursts 100 requests in one second trips the rate ceiling even if its monthly total is tiny. A steady app that polls all day can stay under the rate ceiling and still exhaust its monthly volume.
The second thing to understand is that most large providers do not count raw requests. They count weighted units. Alchemy meters "compute units" (CU) and QuickNode meters "API credits," and a heavy method costs many times more than a light one. Two apps making the same number of requests can consume wildly different amounts of quota depending on which methods they call. This is why "requests per second" comparisons between providers mislead people: the real question is how much work your traffic represents.
If you are new to how this infrastructure fits together, start with our overview of blockchain RPC and node infrastructure — it explains what an RPC endpoint is actually doing when it answers these calls.
More in Node & RPC Infrastructure
Read the error before you fix it
Throttling shows up in a few different costumes, and the right fix depends on which one you are seeing.
HTTP 429 "Too Many Requests." This is the standard web status code for rate limiting, defined in RFC 6585 (published April 2012). It usually means you exceeded the per-second ceiling. Some providers include a Retry-After header telling you how long to wait — honor it if present.
JSON-RPC error `-32005`. Inside a JSON-RPC response body, this code signals a resource or rate limit. You get an HTTP 200 with an error object inside, which is why naive error handling misses it. Always inspect the response body, not just the status code.
"Monthly capacity reached" or a dashboard email. This is the volume ceiling, not the rate ceiling. Backoff will not help; your quota is gone until the cycle resets or you upgrade. The fix here is reducing total consumption (caching, batching, cheaper methods) or paying for more.
Silently degraded responses. A few providers throttle by queueing or slowing responses instead of rejecting them. If your p95 latency suddenly grows while your request rate is flat, check your usage dashboard before blaming the network.
One diagnostic habit is worth building: log the JSON-RPC method name with every failure. Ten minutes of logs usually shows that one or two methods — often eth_getLogs over wide block ranges, or eth_call in a tight loop — account for most of your consumption. Fixing the top method is worth more than any global tweak.
It also helps to know what a normal baseline looks like. A well-behaved frontend read path settles into a steady rhythm tied to block production: a burst of reads when a new block lands, then quiet until the next one. If your request graph instead shows a flat, high-frequency hum, something is polling on a timer rather than reacting to the chain, and that timer is where your quota is going. Providers' usage dashboards break traffic down by method and by hour; fifteen minutes there tells you more than an afternoon of guessing.
Six fixes, from fastest to most durable
1. Exponential backoff with jitter
Retry failed calls with a growing delay and a small random offset (jitter) so that a fleet of clients does not retry in lockstep. This does not reduce your usage, but it turns hard failures into short delays and stops retry storms, where failed calls are retried instantly and make the throttling worse. Backoff belongs in every production app regardless of any other fix.
2. Batch requests and multicall
JSON-RPC supports sending an array of calls in one HTTP request, and on EVM chains the Multicall3 contract aggregates many eth_call reads into a single call. Reading 100 token balances drops from 100 requests to 1. Note that some providers still count the inner calls toward weighted usage, so batching mainly defeats per-request overhead and rate ceilings; check your provider's documentation for how it meters batches.
3. Cache repeated reads
Most dapps re-fetch data that has not changed. Token names, decimals, and symbols never change. Contract state only changes when a transaction touches it, which means once per block at most. A cache keyed by block number gives you perfect freshness with a fraction of the calls: fetch once per new block, serve everything else from memory or Redis. For frontends, even a 10-second in-memory cache cuts traffic dramatically when several components request the same data.
4. Subscribe instead of polling
Polling asks "anything new?" over and over; subscriptions push updates when something actually happens. Over WebSocket, eth_subscribe with the newHeads topic delivers each new block as it arrives, so your app reacts in one message instead of dozens of empty polls. If you cannot hold a WebSocket open, poll at the chain's block time — roughly every 12 seconds on Ethereum mainnet — rather than sub-second.
5. Split traffic across keys or providers
Separate your traffic by purpose: one key for the user-facing frontend, another for background indexing jobs. A runaway backfill job then exhausts its own quota instead of taking your product down with it. Running two providers with client-side failover also removes the single point of failure that a rate limit represents. Keep the routing logic simple — weighted round-robin with health checks is enough.
One warning on this fix: splitting keys does not reduce total consumption, it only isolates blast radius. If your overall usage is growing past what free tiers cover, key-splitting delays the reckoning by weeks at best. Treat it as an availability measure, and pair it with the consumption fixes above rather than using it to dodge them.
6. Run your own node
Your own node has no metered quota at all; the only limits are your hardware. It is the durable endgame for heavy, steady workloads, but it comes with sync time, disk requirements measured in terabytes, and on-call responsibility. Our guide to running your own Ethereum node walks through the real requirements. The break-even math is in the next section.
What the free tiers are actually worth
Provider marketing pages quote big numbers in incompatible units. The way to compare them is to convert everything into "simple requests per month," using each provider's own published limits and a stated assumption about your traffic. Here is that math for two of the most used providers, using their published limits as of September 2026, assuming an average weighted cost of 25 units per call (a mid-weight mix of eth_call and light methods — your mix will differ; recompute with your own average):
| Option | Published free allowance | Rate ceiling | Simple requests/month (at ~25 units/call) | Cost of the next tier |
|---|---|---|---|---|
| Alchemy free | 30M compute units/month | 500 CU/s | ~1.2M | Pay-as-you-go at $0.45 per 1M CU |
| QuickNode free | 10M API credits/month | 15 requests/s | ~0.4M | Build plan, $49/month |
| Your own full node | Unmetered | Your hardware | Effectively unlimited | ~$40–80/month (server) or ~$1,500–2,500 up front (home hardware) |
Two conclusions fall out of this table. First, the free tiers are genuinely large for a small app: at 1.2 million simple requests per month, a frontend serving a few hundred daily users fits comfortably if it caches. Second, the crossover point for self-hosting arrives faster than most people expect. At Alchemy's pay-as-you-go rate of $0.45 per million CU, a workload consuming 5 billion CU per month (heavy indexing territory) costs roughly $2,250 — while a capable dedicated server runs one to two orders of magnitude less. The catch is operations: a node you run badly is worth less than a rate-limited provider that stays up.
To make the math concrete, here is a worked example. Suppose your app serves 2,000 daily users, and each visit triggers 40 RPC reads: balances, prices, and a few contract views. That is 80,000 requests a day, or about 2.4 million a month. At a 25-unit average, you are consuming roughly 60 million weighted units per month — double Alchemy's free allowance. Now apply fix 3: a per-block cache on your backend means those 40 reads happen once per block instead of once per visitor. If your data spans 20 distinct values refreshed every 12 seconds, your upstream traffic drops to about 144,000 requests a day total, regardless of user count — and most of those return unchanged data you could cache even longer. The optimized version fits inside the free tier with room to spare. The unoptimized version costs money forever and scales linearly with your success, which is the worst possible cost curve for a growing product.
A decision rule that holds up well: choose optimization first (fixes 1–4) whatever your size, choose a paid tier if your optimized usage still exceeds free limits and your monthly bill stays under the cost of the hours you would spend running infrastructure, and choose your own node if your workload is heavy, steady, and latency-sensitive — or if you need archive data at volumes where per-request pricing gets punishing. Skip self-hosting if nobody on the team wants to own it; an unmaintained node fails at the worst moment.
Which fix fits your situation
Situation 1: A dapp frontend that breaks during traffic spikes
Your app works in testing and fails when real users arrive, because every visitor's browser hits your RPC endpoint directly. Prioritize caching (fix 3) behind a small backend or edge function, so a thousand users share one set of upstream calls instead of multiplying them. Add backoff (fix 1) in the client for whatever still goes direct. Most spike-driven 429s disappear when reads are shared; you rarely need a paid plan for this pattern.
Situation 2: A trading or monitoring bot that polls aggressively
Your bot polls prices or mempool state many times per second, and the throttling costs you money because reactions arrive late. Move to WebSocket subscriptions (fix 4) so you act on pushed events instead of racing a polling loop, and split keys (fix 5) so your bot's consumption cannot break anything else you run. If milliseconds genuinely matter to your strategy, this is also the situation where a local node (fix 6) pays for itself — not because it is cheaper per request, but because you stop sharing a queue with strangers.
Situation 3: An indexer or analytics backfill that burns a month of quota in a day
Backfilling history means millions of eth_getLogs and eth_getBlockByNumber calls, and weighted metering makes log scans expensive. Batch aggressively (fix 2), keep block ranges per eth_getLogs call modest so responses stay under provider caps, and checkpoint your progress so a failure resumes instead of restarting. For one-off backfills, a temporary paid month is usually cheaper than engineering time. For continuous indexing, run the numbers from the table above — sustained heavy indexing is the clearest case for your own archive node.
FAQ
Do rate limit errors mean my transactions failed? Not necessarily. A throttled eth_sendRawTransaction was rejected before reaching the network, so it is safe to retry the same signed transaction — the nonce protects you from double-spends. But a throttled read after sending tells you nothing about the transaction itself; check its status once your requests go through.
Why do I get 429s when my dashboard shows I'm under my monthly limit? Because the per-second ceiling and the monthly volume are separate limits. Bursts trip the first without denting the second. Smooth your traffic with a client-side queue or token bucket to stay under the rate ceiling.
Are public RPC endpoints a real alternative? Public endpoints (like those listed on chain documentation sites) are fine for experiments, but they carry the strictest limits of all and no support or uptime commitment. Treat them as a fallback of last resort, never as production infrastructure.
Does switching providers fix rate limiting? It buys headroom, not immunity. Every hosted provider meters usage somehow. If your app's request pattern is wasteful, you will hit the next provider's ceiling too — fix the pattern first, then choose a provider sized for what remains.
How do I know which of my calls cost the most? Log the JSON-RPC method for every request, then check it against your provider's method cost table. Providers publish per-method weights (Alchemy's compute unit table, QuickNode's credit table). Heavy log scans and traces usually dominate.
Is a WebSocket connection counted differently from HTTP requests? Usually yes. Providers typically meter each message or subscription event, and some also cap concurrent WebSocket connections separately from request rates. A quiet subscription that only delivers new block headers is far cheaper than the polling it replaces, but a firehose subscription like pending transactions can consume quota faster than any polling loop. Check the per-message costs before subscribing to high-volume topics.
Sources
[Alchemy pricing
[QuickNode pricing
[RFC 6585
Ethereum.org JSON-RPC API documentation (accessed September 2026)
