An RPC outage can hide a chain without stopping it

When an RPC endpoint fails, switch the connection before assuming the blockchain is down: the endpoint is the doorway a wallet or app uses to read chain data and submit transactions, not the chain itself. The distinction matters because a provider outage may leave blocks advancing while one wallet shows errors, whereas a network-wide halt cannot be fixed by changing providers. Check whether the chain is still producing blocks, then choose the least risky way to read or broadcast what you need.

How can you tell whether the chain is down or just the RPC?

Compare the endpoint’s failure with independent views of the chain: if an explorer or another endpoint shows recent blocks arriving, the problem is likely the service you were using. A wallet error alone is weak evidence because it may come from a provider outage, a local connection issue, a rate limit, or a mismatch between the wallet’s selected network and the endpoint.

Start with read-only checks. Open a block explorer for the correct network and look at the latest block or slot, then compare it with the wallet’s displayed network and recent activity. If the explorer is also stale, check another independent view if available. Explorers often depend on their own infrastructure, so one working page does not prove that every node or transaction path is healthy; it does give you a separate signal from the failed wallet connection.

Also distinguish a chain-wide slowdown from a single service failure. A replacement endpoint can restore access if the chain is producing blocks and that provider is reachable. It cannot make a halted or congested network confirm a transaction. If your task is a transfer between networks, the choice of route introduces a separate set of trade-offs; see the Acrossbridge guide to choosing a transfer route for that decision.

What should you try when your wallet cannot connect?

Try another endpoint for the same network, supplied by the chain’s official documentation or a provider you already trust. Many wallets let you change the RPC URL in network settings. Confirm that the replacement serves the intended network before relying on its balances or sending a transaction: a similarly named test network or a custom chain can look convincing while showing entirely different state.

For a quick comparison, use these options in order of what they can tell you:

• Another RPC endpoint: useful for checking current state and submitting a transaction, but it may have its own outage, limits or data lag.
• A block explorer: useful for checking blocks and transaction status; it usually cannot replace the wallet for signing or sending.
• A self-hosted node: offers control over the connection, but needs setup, storage, maintenance and enough time to sync before it can help.
• Wait for the original provider: often the simplest choice if the transaction is not urgent and the provider reports a temporary incident.

For most people, a second trusted endpoint is the practical fallback; running a node makes sense when independent access is a continuing need and you can maintain it. A second endpoint is still a third party, so consider whether it can associate your network requests with your IP address or account. Do not enter a recovery phrase or private key into an RPC provider’s site or support form. Your wallet should sign locally, and the endpoint should only receive the request or signed transaction needed to use the chain.

Is it safe to resend a transaction through another RPC?

First establish whether the transaction was already broadcast or confirmed. Search for its transaction hash in an explorer, and check the wallet’s pending activity before creating a replacement. A timeout means the wallet did not receive a clear answer; it does not prove the network never received the transaction.

If you have the signed transaction data and the wallet supports rebroadcasting it, sending the same transaction through another endpoint generally avoids creating a second, distinct payment. On account-based chains, a replacement transaction may use the same account nonce, but changing fees or transaction details can alter what gets executed. On chains with expiring transaction data, a saved transaction may stop being valid after a period. The wallet’s chain-specific transaction flow determines what can safely be retried.

When status remains uncertain, avoid repeatedly signing new transfers or changing fees at random. Confirm the destination, amount, network and transaction history first. If the endpoint is merely lagging, it may show an old balance or miss a recent confirmation; compare the transaction hash and block progress with another source before acting on that view.

What signals show that access has recovered?

Look for fresh blocks, a wallet that can load current balances, and a transaction receipt or confirmation visible through an independent source. If blocks advance but your transaction remains pending, the chain is reachable and the issue has shifted from access to transaction processing. If multiple independent views stop advancing, changing RPCs is unlikely to solve it.

Keep the endpoint that worked available as a fallback, but return to your normal connection once its provider confirms recovery and its data is current. The useful signals are concrete: the provider’s incident update, the latest block or slot advancing, and the transaction hash moving from pending to confirmed. Together, they show whether the doorway reopened and whether the chain completed the action.