How do I check Polygon RPC status and keep RPC healthy?

When developers search for "Polygon RPC status," they usually want one of three things: confirmation that the Polygon network itself is producing blocks, a way to check whether their own RPC endpoint is healthy, or a quick answer to "why are my Polygon calls failing right now?" This page answers all three, then helps you decide whether to keep using a shared endpoint or move to a managed RPC API or a dedicated Polygon node.

Diagnose first: is it the network or your endpoint?

Before you change providers or restart anything, separate network-level problems from endpoint-level problems. Polygon mainnet (chain ID 137) is a busy network, and most "RPC status" complaints trace back to the endpoint, not the chain.

A fast way to confirm the chain is alive is to read the latest block number from two independent endpoints. If both agree and the number is advancing, the network is fine and the issue is your endpoint or your client.

curl -s https://polygon.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Run it twice a few seconds apart. A rising hex block number means Polygon is producing blocks. A static number, a timeout, or a JSON-RPC error points at the endpoint.

What "RPC status" actually measures

There is no single global Polygon RPC status number. Health is a combination of signals, and different workloads care about different ones.

• Head freshness — how far the endpoint's latest block is behind the chain tip. A few blocks of lag is normal; hundreds means the node is struggling.
• Block production — whether new blocks keep arriving. This is a network property, not something an RPC provider controls.
• Availability — the share of requests that return a valid response instead of a timeout or 5xx.
• Method coverage — whether archive, trace, or log queries are supported for the ranges you need.
• Latency — round-trip time for common calls like eth_call and eth_getBalance.
• Rate limits — how many requests per second your key or IP is allowed before throttling.

When people say "Polygon RPC is down," they usually mean one of these degraded, not that the chain stopped. Naming the specific signal makes the fix obvious.

Probe your endpoint like a monitoring system

A one-off curl tells you the endpoint is reachable right now. Production teams need a repeatable probe. The pattern below checks head freshness and latency together, which is what you actually alert on.

// health-probe.mjs
const ENDPOINT = process.env.POLYGON_RPC_URL; // e.g. your OnFinality endpoint

async function rpc(method, params = []) {
  const started = Date.now();
  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const json = await res.json();
  return { result: json.result, error: json.error, ms: Date.now() - started };
}

const head = await rpc("eth_blockNumber");
console.log("head:", parseInt(head.result, 16), "latency_ms:", head.ms);

const chainId = await rpc("eth_chainId");
console.log("chainId:", parseInt(chainId.result, 16)); // expect 137

Run this on a schedule and store the results. You want to know your endpoint's normal head lag and latency so you can spot the moment it drifts. Alert on trends, not single failures.

Chain settings at a glance

If you are wiring Polygon into a wallet, a backend, or a new environment, use the canonical values. Wrong chain IDs and stale RPC URLs are a frequent cause of "status" confusion.

For a wallet or client config, the shape looks like this:

{
  "chainId": "0x89",
  "chainName": "Polygon Mainnet",
  "nativeCurrency": { "name": "POL", "symbol": "POL", "decimals": 18 },
  "rpcUrls": ["https://polygon.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://polygonscan.com"]
}

Note that 0x89 is 137 in hex. If a tool shows the wrong chain ID, transactions can be signed for the wrong network even though the RPC endpoint responds normally.

Reading the errors behind a "down" status

Most Polygon RPC failures map to a small set of causes. Match the message to the fix before you escalate.

• HTTP 429 / "rate limit exceeded" — you are sending more requests than the endpoint allows. Batch calls, cache reads, or move to a plan with higher throughput. See RPC pricing for capacity options.
• execution timeout or connection reset on eth_getLogs — the block range is too wide or the endpoint is not archive-capable. Narrow the range and paginate.
• method not found — the endpoint does not expose that method (common with trace or debug calls). Confirm the provider's supported API surface.
• Stale head / old eth_blockNumber — the node is behind. Fail over to a second endpoint and investigate.
• nonce too low or replacement transaction underpriced — this is a transaction-level issue, not an RPC outage. Check your nonce handling.
• TLS or DNS errors — local network or certificate problem, not Polygon. Test with curl -v.

If your app depends on WebSocket subscriptions, remember that eth_subscribe needs a WS-capable endpoint. A healthy HTTP endpoint does not guarantee WS works.

When a shared endpoint is enough, and when it is not

Public and shared endpoints are fine for development, scripts, and low-volume reads. They become a liability when you need predictable throughput, archive history, trace data, or WebSocket streams under load.

OnFinality offers both a managed RPC API service and dedicated nodes for Polygon, so you can start shared and move to isolated capacity as your workload grows. The right choice depends on your request profile, not on a single status number.

A practical failover setup

Even a healthy endpoint can degrade. A simple failover pattern keeps your app online while you investigate.

const ENDPOINTS = [
  process.env.POLYGON_RPC_PRIMARY,
  process.env.POLYGON_RPC_SECONDARY,
];

async function sendWithFailover(payload) {
  for (const url of ENDPOINTS) {
    try {
      const res = await fetch(url, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(payload),
        signal: AbortSignal.timeout(4000),
      });
      if (res.ok) return await res.json();
    } catch (err) {
      // try the next endpoint
    }
  }
  throw new Error("All Polygon RPC endpoints failed");
}

Keep the secondary endpoint on a different provider or region so a single incident does not take both down. Log which endpoint served each request so you can spot patterns.

Operational checklist for Polygon RPC

• Confirm chain ID 137 (mainnet) or 80002 (Amoy) in every environment.
• Monitor head lag and latency, not just reachability.
• Cache read-heavy calls and batch where the client supports it.
• Paginate eth_getLogs and confirm archive support for historical ranges.
• Test WebSocket subscriptions separately from HTTP.
• Configure at least one failover endpoint.
• Review rate limits against your peak request rate before launch.

Browse the full list of supported RPC networks to see where Polygon fits alongside other chains you run.

Key Takeaways

• "Polygon RPC status" is not one number; it is head freshness, availability, method coverage, latency, and rate limits combined.
• Confirm the chain is producing blocks with two independent endpoints before blaming the network.
• Most failures are endpoint-level: rate limits, missing archive/trace methods, or stale heads.
• Match chain ID 137 and the correct RPC URL when configuring wallets and clients.
• Use a managed RPC API or dedicated node when shared endpoints cannot meet your throughput, history, or isolation needs.

Frequently Asked Questions

Is Polygon RPC down right now? There is no single global status. Check whether the chain is producing blocks via a block explorer, then probe your own endpoint for head lag, latency, and errors. If two endpoints disagree, the problem is usually the endpoint, not Polygon.

Why does my Polygon RPC return 429? A 429 means you are exceeding the endpoint's rate limit. Reduce request volume, batch or cache calls, or move to a plan with higher throughput.

What is the Polygon mainnet chain ID? Polygon mainnet uses chain ID 137 (0x89). The Amoy testnet uses 80002.

Why does eth_getLogs fail on old blocks? The endpoint may not be archive-capable, or the block range is too wide. Narrow the range and confirm the provider supports historical queries.

Do I need a dedicated Polygon node? Only if you need predictable throughput, archive or trace data, WebSocket streams under load, or strict isolation. For light usage, a shared or managed endpoint is usually enough.

Does OnFinality support Polygon? Yes. OnFinality provides Polygon RPC through its managed RPC API service and dedicated nodes. See the Polygon network page for endpoint details.