Test your RPC speed & reliability. Free benchmark against GetBlock

The benchmark sends a bounded number of read-only JSON-RPC requests during a short test window. The exact number depends on the current benchmark duration, the selected “What are you building?” profile, endpoint response time, and how quickly each provider responds before the timeout. It is designed to be a lightweight diagnostic, not a heavy load test. The benchmark report shows the total request count so you can see how much traffic was used in that run.

Yes, you can test a private RPC endpoint that includes an API key in the URL. The tool masks the endpoint in reports and does not display the full URL back to the page. For security, you should only paste RPC URLs, never private keys, seed phrases, wallet secrets, or signing credentials. If your provider supports domain or IP allowlists, make sure the benchmark server is allowed to reach the endpoint.

This public benchmark is intended for mainnet RPC endpoints only. GetBlock baselines in this tool are configured for mainnet comparisons, so a testnet or devnet endpoint can produce misleading latency, freshness, and method-compatibility results. If the pasted endpoint reports a testnet chain ID or network identity, the tool should block the run and ask you to use a mainnet endpoint for the selected protocol. Testnet benchmarking should use a separate baseline, separate methodology, and clearly labeled testnet results.

Rate limiting detected means the endpoint returned a response that looks like request throttling, commonly HTTP 429 or a provider error message such as too many requests. In the report, this appears in Findings because it is usually an actionable production risk. Public RPC endpoints often rate-limit sooner than paid or private endpoints. In production, rate limits can cause failed page loads, delayed indexing, or broken bot workflows unless you add retries, caching, or fallback RPC routing.

Public RPC endpoints are shared by many users, so their latency and reliability can change quickly depending on total network demand. A paid or private endpoint usually has dedicated capacity, higher rate limits, better routing, and more predictable infrastructure. A public endpoint can be useful for testing, but it may show higher p95 latency, more timeouts, or rate-limit errors under repeated requests. That difference is exactly why the benchmark compares latency and reliability, not just whether the endpoint responds.

Freshness measures whether your RPC endpoint is caught up with the latest block or slot compared with the GetBlock baseline. In the report, the latest block check shows the chain position for both endpoints and the block or slot difference between them. An endpoint can respond quickly but still be behind the current chain state. That difference also feeds into Production fit because stale data can affect wallets, indexers, trading bots, and other production applications.

A fair RPC comparison sends the same read-only methods, with the same timeout, during the same short time window, from the same benchmark server, to mainnet endpoints on the same protocol. If those conditions change, the comparison becomes noisy and easy to misread. This tool keeps the request profile aligned so Provider performance, Latency breakdown, Findings, and Production fit are based on the same benchmark run.