19% of requests were rate limited (1603 of 8227); excluded from availability
12 providers scored against each other.
Score breakdown
How the composite score is composed
Component
Weight
Measured
Score
How it is measured
Availability
40%
7.64 %
7.6
Share of requests that succeeded, excluding rate limits and unsupported methods.
Latency
30%
7190.55 ms
0.0
Scored on p95 relative to the cohort, log-scaled so a 10x difference is not a 10x penalty.
Correctness
20%
99.22 %
99.2
Share of responses that were valid. Also caps the overall score, so speed cannot compensate for wrong answers.
Head freshness
0%
not applicable
—
Not applicable across chains: blocks and slots are different units on different scales, so no cross-chain average is published. See the chain pages for this provider's head lag.
Outcome breakdown
Failures are classified rather than collapsed into one count. Our own failures are shown for transparency but are never counted against the provider.
Request outcomes and how each is treated
Outcome
Count
Share
Treatment
Successful
506
5.81%
—
Provider failure
4,353
49.97%
Counted against provider
Network failure
3,368
38.66%
Counted against provider
Rate limited
1,603
18.40%
Excluded from availability
Unsupported method
0
0.00%
Capability fact, not a failure
Agent error
0
0.00%
Ours, never the provider
Measurement error
484
5.56%
Ours, never the provider
What it says it permits
The only figures on this site that are not measurements. A limit is a claim the operator makes, so it is quoted with the page it came from and the day it was read — never inferred from a refused request, which would put a number against a company that never stated it.
1RPC does not publish a numeric limit that could be found in its own documentation. Several public endpoints state only that a request may be refused — which is worth knowing before depending on one, and is why this says so rather than showing nothing.
What it promises about staying up
The status page judges every provider against an objective this site publishes. That is not an SLA, and a provider that misses it has not broken a promise — so what it actually promised, where it promised anything, belongs here in its own words. The objective
1RPC does not publish an availability commitment that could be found in its own documentation. That is the common case for a public endpoint and is worth knowing before depending on one: the availability figures on this site are measurements against a bar this platform set, not against anything 1RPC agreed to.
Reliability record
An availability percentage has no shape. This is the shape: what departed from this provider’s own normal behaviour, and what its normal behaviour already is. How an incident is decided
Departures from normal · last 30 days
None. Across the last 30 days, 1RPC did not depart from its own usual behaviour on any measured call for long enough to count as an incident.
Persistent conditions
Calls that fail, or are refused, at about the same rate every day. These are not events — they are what this provider does — and none of them will be different tomorrow.
The same measurements, grouped by the vantage point they were taken from. Latency is a property of a network path, so a provider fast from one region is not necessarily fast from another — and the composite score above is an average across whichever regions are reporting.
A live badge for 1RPC on BSC, free to use. It renders from the current measurement each time it loads, so it cannot be frozen at a good day — which is what makes it worth putting in a README. Every badge and parameter
score
The composite score, coloured by band.
Markdown
[](https://rpcnode.io/providers/onerpc)
HTML
<a href="https://rpcnode.io/providers/onerpc"><img src="https://rpcnode.io/badge/provider/onerpc.svg?chain=bsc" alt="1RPC on RPCNode.IO"></a>