How to read SolidRPC reliability metrics

The homepage presents a rolling 30-day observation window and a calculation timestamp. Read both. A snapshot can cover a recent period without being a live reading of the current minute. A delayed snapshot means the last successful calculation is older than expected. Unavailable means a value cannot be presented from the available data.

Missing monitoring data must remain unknown. It should not be filled with invented successful observations. The timestamp describes the last successful calculation, not merely the latest attempt to refresh the page.

This metric uses internal monitoring observations of gateway metrics endpoints. For each evaluated point, it checks whether at least one gateway target is reachable while the monitoring observer is healthy. The percentage summarizes those observations across the window. Collection gaps are absent from this calculation.

That scope is precise: it indicates gateway reachability from the internal monitoring system. It does not measure every customer network path, hostname lookup, authentication attempt, or RPC method result. Evaluating a complete public request requires an external client to connect, authenticate, send a representative call, and validate the returned result.

Use the fleet figure as one operational signal. Use workload measurements to assess the experience of your application.

The published rate uses recorded routing failures classified as warning or critical, divided by those failures plus recorded successful requests. It is measured after platform routing and retries. It is not a count of every unsuccessful first upstream attempt.

This explains how internal retries can occur while the final error rate remains low: an intermediate failure can still lead to a successful terminal outcome. It also explains why a fleet aggregate cannot predict every chain or workload. Different methods, request sizes, and historical depths create different populations.

When testing a batch, retain every individual result or error. Treating the outer HTTP status as the outcome of every inner call would lose information that your application needs.

Requests completed after retry counts recorded successes on attempt two or later. It shows the volume of successful later attempts. It does not identify a provider switch, a distinct incident, or a particular amount of downtime avoided.

Median agent reaction time measures the interval from an alert being received to work starting across the sampled incidents. It is not time to detection from the original fault, time to full repair, or a customer support response commitment. The sample count matters when interpreting that median.

Read these measures together: routing can recover a request while repair work continues, and quick work initiation does not establish that the entire incident was resolved quickly.

Covered Request Availability uses eligible account calls on selected, traffic-qualified networks during the applicable billing period. The accepted terms govern qualification, exclusions, settlement, and automatic next-invoice credits. The public SLA guide summarizes the policy and links to the Service Level Terms.

The classifier evaluates more than HTTP status. A call must meet the applicable response, identity, deadline, and freshness requirements. An intermediate upstream fault followed by a qualifying successful result is assessed on the final outcome. Fleet availability, fleet error rate, and account SLA availability therefore should not be substituted for one another.

Consult your SLA dashboard for the agreement, covered networks, period result, and credits that apply to your account.

Use a fixed set of recent reads, historical reads, logs, and traces representative of your workload. Record client region, method, block context, request count, concurrency, elapsed time, and every outcome. Compare p50 and p95 latency together with correctness and failures.

Keep test retries visible. Report the first-attempt result and the result after the client retry policy separately, so a successful retry does not erase the initial experience. Record monitoring gaps and distinguish a method-specific failure from a whole-endpoint outage.

The benchmark guide explains how to make the test reproducible. The goal is a result your team can inspect and repeat, with a clear relationship between the numbers and the work your application needs.