Solana RPC returning "429 Too Many Requests" and getProgramAccounts timing out: what it means

A "429 Too Many Requests" from a Solana RPC endpoint is the provider shedding your traffic before the node does expensive work, and a getProgramAccounts timeout is the node failing to finish that work in time. Both are symptoms of the same cost asymmetry: a handful of RPC methods cost the serving node orders of magnitude more than they cost the caller to send. getProgramAccounts is the worst of them, because it scans every account owned by a program and filters server-side before returning anything.

Common causes

• You are calling getProgramAccounts against a large program without filters or dataSlice, so the node walks and serialises far more account data than you consume.
• The endpoint is a shared public one, where per-IP rate limits are set low precisely because a few heavy callers can degrade the node for everyone.
• The node lacks the secondary indexes that make program-scoped scans cheap, so each call is a full scan rather than an index lookup.
• The node is already under load, and your request is queueing behind other blocking work until the client gives up.

System-level mechanism

In the Agave client, heavy account scans are pushed onto a bounded blocking-thread pool so they do not stall the async runtime. That pool is shared. When enough expensive calls arrive together, the pool saturates, every queued scan inherits the backlog, and requests start timing out without any single request being malformed. The 429 is the provider's defence against exactly this: shedding load at admission, before the node commits resources. The important property is that the cost is incurred before the caller has proven anything about itself, which is why rate limits bound abuse per key or per IP but do not change the underlying asymmetry.

What this indicates

Routine 429s indicate your read workload is shaped wrongly for a shared endpoint, not that the chain is unhealthy. Timeouts on getProgramAccounts specifically indicate the serving node's blocking capacity is exhausted, by you or by whoever shares the node with you. Either move heavy scans to a dedicated node with the right indexes, or reshape the query so the work is bounded.

Related issues

Stale or inconsistent reads from a node lagging the tip under load; reads degrading while writes fail outright; transactions expiring because a saturated node issued an old blockhash.

Deep references

• Expensive work before authentication sets out the request-cost asymmetry pattern this symptom belongs to.
• We're securing validators at the wrong layer argues why this class of RPC-layer failure is structural rather than configuration error.
• NR-2026-001, Agave RPC architectural findings documents the getProgramAccounts blocking-pool saturation pattern in detail.