429 Too Many Requests on Solana RPC

Root causes

Ranked by frequency. First cause is the one to check first.

1. 01Burst of parallel requests exceeding per-second rate (e.g., Promise.all over 200 `getAccountInfo` calls).
2. 02Daily quota exhausted — check the `x-rate-limit-remaining` header.
3. 03Retry loop with no backoff hammering the endpoint harder on each failure.
4. 04Credit-metered provider running out of monthly credits (Helius, QuickNode).

Fix steps

1. 1

   Batch requests

   Solana RPC supports JSON batch requests — 100 getAccountInfo calls in one HTTP request count as 1 request for rate-limit purposes on most providers. `[{...}, {...}, {...}]` instead of sequential posts.

2. 2

   Add retry with jitter

   On 429, sleep `Retry-After` if present, else 1-2 seconds with randomness. Never retry instantly.

3. 3

   Stream instead of poll

   If you're polling for account changes, switch to gRPC accounts subscription with an owner filter. One stream replaces thousands of polls and is immune to rate-limit cliffs.

4. 4

   Monitor quota remaining

   Log the `x-rate-limit-remaining-day` and `x-rate-limit-remaining-second` headers Subglow and Helius both return. Alert when you're at 80% of the daily cap.

Related errors

• Node is behind (slot lag on RPC)
  Your RPC endpoint is lagging behind the tip of the chain. Symptoms: `getSlot` returns a number much lower than Solana Explorer, `getAccountInfo` returns stale data, `getLatestBlockhash` gives expired blockhashes. Usually a shared-endpoint issue.
• RESOURCE_EXHAUSTED — rate limit on gRPC
  `Status { code: ResourceExhausted }` means the server refused to serve your call because you hit a limit — concurrent streams, messages-per-second, or filter complexity. Unlike HTTP 429, this is a hard rejection: the stream is closed and must be reconnected, not retried on the same channel.