Free RPC endpoints die one method at a time. Here's everything that broke keeping a six-chain frontend alive

tagwall — Sat, 10 Oct 2026 02:55:44 +0000

I run a frontend that reads the same smart contract on six EVM chains, using free public RPC endpoints. Here are a few of the things which cost me downtime, an expensive lesson I hope you can learn from.

Endpoints rot per method, not all at once

This is the one that actually hurt the most. Two providers put eth_getLogs behind an archive token, or dropped it entirely, while still answering eth_call and eth_blockNumber perfectly. Every simple health check including mine, called them healthy. The canvas went blank on 4 of 6 chains while the page header kept rendering fine, because the header only needs eth_call.

The fix is to probe an endpoint the way your app actually uses it, not the way a status page would. Check the chain id, check CORS from your real origin (a CORS failure from the deployed site is invisible in curl), and run a real getLogs at that chain's own chunk size. If the probe isn't a miniature of your actual read path, it's useless.

I got that wrong in my own probe for months, in the other direction. It only ever tested a window starting at the deploy block, so it graded every endpoint on archive depth. But the app doesn't read from the deploy block any more. It scans forward from a snapshot, so the live path only asks for the last few thousand blocks. The probe was failing endpoints that were serving my real traffic fine. It now tests both windows and reports them separately, because "can't serve archive" and "can't serve anything" are different problems and only one of them can cause an outage.

getLogs chunk sizes aren't portable

One chain caps the range at 1,000 blocks. Another needs 500k-block chunks to keep the number of calls survivable. The only alternative provider for that second chain caps at 10k, which makes it useless as a backup even though it looks like a valid fallback. Chunk size has to be configured per chain, and a fallback endpoint is only a fallback if it can serve the same range.

viem details that cost me time

http() defaults to a 10 second timeout. That's long enough for a dead endpoint to stall a page load instead of failing over.
fallback() always starts at the first endpoint in its list, so that endpoint absorbs every request and its rate limit becomes yours. If you want load spread, you need your own rotation.
multicall's batchSize is bytes of calldata, not number of calls. I found that out the way you'd expect.

A rewind must only ever move the cursor backwards

My worst bug. A keep-current pass set the cursor to head - depth * 4 outright. On a slow chain that's a rewind, which is what it was written to do. On a chain producing 600 blocks a minute, it's a 700-block jump forward that silently drops events.

cursor = min(cursor, head - depth * 4) is the whole fix, and it should have been the whole implementation.

Stop reading history from RPC on page load

In the end I stopped reading history from RPC on first load at all. Everything I needed was already in each paint transaction's calldata, so a cron job decodes it into Cloudflare KV, and the browser fetches one snapshot and only scans forward from there. A cold page load went from about 126 RPC calls to a handful.

The constraint that shaped it is the KV free tier's 1,000 writes a day. The rule became never write on a schedule, only when something actually changed. A cron that writes every run will use up that quota before lunch.

It kept happening while I wrote this

Two of the six chains rotted in the same week, which is why I finally wrote any of this down.

On one chain, the last working endpoint quietly tightened its getLogs range from 9,500 blocks to 5,000, below the chunk size I was asking for. Nothing visibly broke, because my paginator halves the chunk and retries, so it just wasted three failed calls before every successful one. Two days later the same endpoint stopped serving getLogs altogether, with a 30 second server-side timeout, while eth_call and eth_blockNumber kept answering in under 50ms.

Slow failure turned out to be worse than fast failure. A dead endpoint gets skipped in milliseconds. One that accepts your request and times out after 30 seconds stalls whichever page load was unlucky enough to get it. I pulled it from the pool, and that chain now has no free endpoint that will serve a query from the deploy block, so the snapshot isn't an optimisation there any more. It's the only way the history can be read at all.

Meanwhile, on a second chain, both main public endpoints dropped their getLogs range to 2,000 blocks, four days after passing the same probe at 9,500. Both are run by the same company. I had four endpoints listed for that chain and thought I had redundancy. Two were the same operator, one had been discontinued, and one had started answering invalid params to every getLogs call. Count operators, not URLs.

What it's for

The contract is a million-pixel canvas called tagwall, deployed on six chains, and the contract was genuinely the easy part. Every pixel is stored on chain, there's no owner or admin, and the frontend is open source. If you're curious, it's at https://tagwall.io, and I'm happy to go deeper on any of the above in the comments, the RPC probing especially.

DEV Community: tagwall