What happens when your RPC endpoint runs out of compute units
When an nodes/rpc-endpoint-basics/">RPC endpoint runs out of compute units, every request you send to it fails with an error indicating you have exceeded your provider’s usage limit. You cannot read blockchain data, submit transactions, or call smart contracts through that endpoint until the limit resets or you upgrade your plan. The specific error message varies by provider but commonly includes phrases like "exceeded rate limit," "quota exceeded," or "insufficient compute units."
What compute units actually measure
Compute units are a provider’s way of billing for the work your requests force their servers to do. Not all RPC calls cost the same number of units. A simple eth_blockNumber might cost one unit, while a complex eth_call against a contract that iterates many storage slots can cost dozens. Providers publish unit cost tables for each method, typically based on how much CPU time, memory, and database lookups the request requires.
When you use a free tier, you get a fixed pool of compute units per time window - often per day or per month. Once you exhaust that pool, the endpoint returns errors for all subsequent requests until the window resets. Paid plans simply give you a larger pool and sometimes a per-second burst allowance.
Why your endpoint ran out
The most common reason is that a single application or script is making more requests than the plan covers. A DeFi dashboard that polls balances every few seconds, a bot that scans logs in a tight loop, or a wallet that refreshes token metadata aggressively can all burn through thousands of units in minutes. Another frequent cause is a poorly optimized eth_call that reads the same contract state repeatedly instead of batching reads into a single call.
Less obvious causes include: - A misconfigured websocket subscription that reconnects and re-subscribes on every disconnect, doubling or tripling the request count. - An infinite retry loop in your code that does not respect the provider’s rate-limit headers. - Shared API keys: if you put a free-tier endpoint URL in a public frontend, every visitor consumes from the same pool.
Short-term fixes
1. Check your remaining compute units. Most providers offer a status endpoint or dashboard that shows your current usage and reset time. Look for HTTP response headers like X-RateLimit-Remaining or Compute-Units-Remaining on any successful request. If you can still make one call, use it to check your balance.
2. Wait for the reset. Free tiers typically reset daily or monthly. Note the exact reset time from the provider’s documentation or your account page.
3. Switch to a backup endpoint. If you followed the multi-provider failover setup covered elsewhere on this site, your application should automatically fall back to a secondary provider. If you have no failover configured, add a second free-tier endpoint from a different provider immediately - but be aware that both may have similar limits.
4. Reduce your request rate. Add delays between calls. For batch-friendly operations like fetching token balances, use eth_call with multiple calls in a single batch request rather than separate HTTP requests.
Long-term solutions
Upgrade your plan. Paid tiers offer compute unit pools large enough for most personal or small-team use. Compare unit costs per dollar across providers; some charge less for archive data or for eth_getLogs queries.
Optimize your queries. Cache blockchain data you already fetched. If you poll the same contract state every 10 seconds, store the result locally and only re-fetch when the block number changes. For event logs, use smaller block ranges and narrower filter topics.
Run your own node. This is the only way to eliminate compute unit limits entirely. A local node charges no per-request fees, but adds hardware, bandwidth, and maintenance costs. A full node with pruning consumes about 1 - 2 TB of storage and requires a reliable internet connection to stay synced. Archive nodes need 10 TB or more. Running a node is worthwhile if you make tens of thousands of requests daily, need low latency, or require unrestricted access to historical data.
When you should just pay
If your usage is steady and predictable - for example, a personal trading bot that makes 200 calls per hour - paying for a small plan is almost always cheaper and simpler than running a node. The monthly cost of a starter paid plan is usually less than the electricity and bandwidth for a dedicated machine. Only consider running your own node when your request volume exceeds what paid plans offer at a reasonable price, or when you need direct control over the node’s configuration and data retention.
When running your own node makes sense
Run a node when: - You need more than a few hundred thousand compute units per day. - You require archive data older than what most providers keep. - Your application is latency-sensitive and a local connection is measurably faster than any provider. - You want to avoid depending on a third party that could change pricing or terms.
Otherwise, a paid provider plan is the practical choice. Compute unit exhaustion is not a technical failure - it is a billing signal. Treat it as one.
Not financial advice. starname.me publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.