OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
⌁

RPC Health Checker

Probe JSON-RPC endpoints from your browser
Result0 findings

    Requests go directly from this browser to the endpoint

    Introduction

    The RPC Health Checker probes JSON-RPC endpoints for Ethereum (EVM), Solana and Cosmos (CometBFT) nodes and reports latency, chain ID, height, sync state and peer count. It is useful before pointing an application, an indexer or a wallet at a new endpoint, and for comparing two endpoints of the same network.

    Every request is made directly from your browser to the endpoint. There is no proxy and no server-side call: the tool builds the JSON-RPC payloads locally, measures the round-trip time and classifies the outcome. If the endpoint blocks the browser with CORS, the tool explains why and shows an equivalent curl command you can run yourself.

    Objective

    • Validate the endpoint URL and reject unsafe schemes (file:, javascript:, data:, ftp:).
    • Probe the standard health methods for Ethereum, Solana or Cosmos and measure latency.
    • Classify the endpoint as healthy, syncing, behind, unavailable or inconclusive.
    • Optionally compare two endpoints of the same network for height gap, chain-ID divergence and version differences.
    • Never claim an endpoint is trustworthy just because it answered.

    Inputs

    • One or two endpoint URLs (https:// preferred).
    • The chain type: Ethereum (EVM), Solana or Cosmos (CometBFT).
    • Nothing is stored, logged or sent to the OthoTools server.

    How it works

    The URL is parsed and validated: only http(s) is accepted, https is preferred, and userinfo or token-looking query parameters are detected and masked before display. http on a public host is rejected because browsers block it as mixed content.

    For Ethereum the tool calls web3_clientVersion, eth_chainId, eth_blockNumber, eth_syncing and net_peerCount. For Solana it calls getHealth, getSlot, getVersion and getIdentity. For Cosmos it reads the REST endpoints /status and /net_info.

    Each call is timed. The results are normalised into an outcome (height, chain ID, version, peers, syncing state, latency) and classified: healthy when the node responds with a current height and is not syncing; syncing when the node reports catch-up progress; behind when a comparison shows a large height gap; unavailable when the request fails or returns a JSON-RPC error; inconclusive when the response shape is unexpected.

    With two endpoints, the heights, chain IDs, versions and latencies are compared and differences are reported as findings.

    Testable example

    Try it — the analysis runs locally in your browser.

    Example

    Chain:   Ethereum
Endpoint: https://eth.example.com
Method:   eth_blockNumber

(second endpoint, optional comparison)
https://eth2.example.com

    Expected output

    web3_clientVersion  Geth/v1.14.11-stable/linux-arm64  ·  212 ms
eth_chainId         1                                  ·  204 ms
eth_blockNumber     21048321                           ·  198 ms
eth_syncing         false                              ·  201 ms
net_peerCount       48                                 ·  215 ms
Status: healthy — responded within ~205 ms average.

    Reading the output

    • A healthy result means the endpoint answers the standard methods and is not reporting sync progress. It does not prove the node is trustworthy, correctly configured or safe to send funds through.
    • Syncing means the node is catching up; applications that need recent state will see stale or missing data until it finishes.
    • A height gap between two endpoints of the same network is normal during brief reorgs; a persistent or large gap suggests one node is unhealthy or partitioned.
    • If CORS blocks the request, the endpoint does not allow browser origins. Run the equivalent curl command from a machine you trust to get the same data.

    Risks

    • A responsive endpoint can still serve stale, wrong or malicious data. Health is not trust.
    • URLs may contain credentials. The tool masks them, but you should remove credentials from the URL before sharing it anywhere.
    • Public endpoints may rate-limit or block repeated probes; do not use this tool as a monitoring daemon.

    Limitations

    • Browser CORS policies may block legitimate public endpoints; the curl fallback covers those cases.
    • The tool checks a snapshot in time; it is not uptime monitoring.
    • It cannot detect consensus-level problems, fee-market manipulation or node misconfiguration beyond the probed methods.

    Official references

    FAQ

    Is it safe to paste an RPC URL here?

    Yes — the request is made directly from your browser and never passes through the OthoTools server. The tool still masks credentials and token-looking parameters on screen and recommends removing them before sharing.

    Why does some public endpoint fail with CORS?

    The endpoint's server decides which browser origins may call it. Many public RPCs do not send CORS headers, so the browser blocks the request even though the endpoint is up. The tool shows an equivalent curl command for that case.

    What does 'behind' mean?

    It comes from the two-endpoint comparison: the height gap between the two endpoints exceeds the threshold for that chain (12 blocks for Ethereum, 150 slots for Solana, 10 blocks for Cosmos). A single-endpoint check cannot determine 'behind' without a reference.