Polygon PoS RPC Incident — Post-Incident Summary

Polygon Mainnet (PoS)
1

Overview

Earlier today, Polygon PoS experienced an issue affecting a subset of Bor nodes getting stalled or falling behind the network tip. Applications may have experienced degraded performance or request failures as many RPC nodes were also affected.

However, the chain remained online and continued producing blocks throughout the incident and did not experience any downtime. A number of RPC nodes remained fully operational during this period and transactions were flowing in and getting processed as usual meaning applications like Polymarket and Courtyard had minimal to zero effect.

Impact

  • Degraded RPC availability across multiple providers

  • Some applications experienced connectivity issues depending on RPC usage

  • The block explorer was temporarily behind due to node lag

  • Lag in finality as many validator nodes were stuck

  • No impact to block production, consensus, or network safety

A list of operational RPC endpoints was shared during the incident to help applications route traffic accordingly.

Root Cause

  • The issue was isolated to Bor, the block-producing and transaction execution layer of Polygon PoS

  • A subset of Bor nodes stalled and required recovery.

Mitigation & Resolution

A war room was activated promptly, and teams worked alongside validators and RPC providers to deploy a fix.

A solution was identified and rolled out to affected operators.

Applications and users: No action required; RPC providers upgraded and recovered service, explorers still syncing.

1 Like
2

Thanks for publishing the post-incident summary, it is useful for anyone running an application on top of the chain. One practical takeaway for app teams, as far as I know, is that a single RPC endpoint can look healthy while sitting several blocks behind the tip, which matches the node lag described here. A simple mitigation is to run a health check that compares each provider’s latest block number against a second provider or a reference value, and to fail over automatically when the gap exceeds a threshold.

For reads, it can also help to use more than one provider with a short timeout and to retry idempotent calls against the next endpoint. For writes, it is worth confirming the nonce and checking the transaction status on a second node before resubmitting, so that a lagging node does not cause a duplicate send. A short list of known-good public endpoints in a post like this is very helpful for that purpose.