Metrics / routstr / success_rate
success_rate
The Routstr network's self-reported request success rate over the trailing 30 days - the Network tab's 'Reliability, as reported' figures, one row. A snapshot, not a series.
unit
ratio
grain
current (UTC)
series
current state
key
routstr.success_rate@current
Parameters
| param | accepted values |
|---|---|
| grain | current - default current (omit to get the default) |
| from / to | current-state snapshot with no time axis - 'from'/'to' are rejected |
| format | csv | markdown |
Query it
MCP tool call against https://dev.nostrolo.gy/mcp (connect your agent):
{
"name": "nostrology_query_metric",
"arguments": {
"metric": "success_rate",
"domain": "routstr",
"grain": "current"
}
}Response: a plain-text envelope (window, freshness, column contract, this page's
caveats) followed by the data table (csv, or format: "markdown") at current grain.
Response columns
| name | type | description |
|---|---|---|
| success_rate_30d | number | 1 - failed_reported / requests_reported, 4 decimals; NULL = no fresh reporter |
| requests_reported | integer | total requests (INCLUDING failed and non-chat) over the fresh providers' own trailing-30d summaries |
| failed_reported | integer | failed requests over the same summaries |
| providers_fresh | integer | included providers whose newest snapshot is at most 7 days old - the population |
What is counted
Included providers whose newest kind-38422 (routstr-analytics-snapshots) event is at most 7 days old; each contributes the total_requests and failed_requests of its OWN trailing-30d summary.
Caveats
- Self-reported twice over: each provider computes its own window and we only aggregate; it counts only providers still talking (both biases point up), and total_requests includes non-chat endpoints - so it is NOT comparable with the successful-only request counts of the other Routstr metrics. Read it as what the still-reporting network says about itself, nothing stronger.
- Every usage number is SELF-REPORTED by each provider's own node in kind-38422 (routstr-analytics-snapshots) events and is unverifiable by construction (RIP-01 payments travel as Cashu tokens in HTTP headers, invisible on Nostr): a node can overstate, understate or stay silent, so read these as what the network says about itself.
Freshness in every response is data-derived: the newest routstr refresh's generation instant (nightly 02:45 UTC; the newest ledger day is the previous UTC day).