monero.fail

monero.fail is the live monitor of public Monero remote nodes — the canonical "which remote node should I point my wallet at?" reference. Probes hundreds of operator-published nodes, charts uptime, exposes a JSON feed at `/nodes.json` for other tools to consume, and provides an onion mirror for Tor users. Listed at Grade A · editor's pick because it solves an unglamorous-but-critical problem: when you don't want to run your own Monero full node, the next-best privacy posture is "pick a remote node deliberately, with operator-publish + uptime data in front of you" — and monero.fail is the directory that makes that choice informed rather than blind.

Background. monero.fail is an independent community-maintained service that probes the public Monero node list and reports liveness. Started by a Monero community contributor and has been the reference node-monitor for several years. Source available, hosted at monero.fail with Tor mirror operator-published at livk2fpdv4xjnjrbxfz2tw3ptogqacn2dwfzxbxr3srinryxrcewemid.onion. Funded by donations + low operational footprint (probe traffic + light-weight web frontend). Cross-referenced in this directory's `/nodes` section as the upstream source of public-node uptime data.

What you trust. monero.fail itself is a monitor, not a node — it doesn't relay your wallet traffic, it doesn't see your wallet queries. The operator only sees: which node operator-published URLs return liveness probes, response latency, and country/transport metadata. What the operator doesn't see: any of your wallet activity. What the operator does see: the list of public Monero nodes (operator-published and crowd-submitted) and their uptime statistics. The trust ask is modest: trust monero.fail's uptime data is accurate; you still pick the actual node you connect to. Onion mirror: operator-published `.onion` for Tor users who want to browse the node list without a clearnet hop.

Operational specs. Probe coverage: hundreds of public Monero nodes including clearnet, Tor (`.onion`), and I2P (`.b32.i2p`) variants. Sort dimensions: uptime percentage, country, transport (clearnet/Tor/I2P), node version, restricted RPC vs unrestricted. API: `/nodes.json` (JSON), `/nodes.txt` (plain text list), `/nodes/<network>.json` (per-network filter). API consumers include Feather Wallet's "pick a node" auto-suggest, Monerujo's default node list, multiple privacy directories (us included), and bots that recommend nodes to new users. Update frequency: probes run continuously; uptime statistics weighted over 24h / 7d / 30d windows. Tor onion operator-published; the monitor itself is fully usable over Tor with no JS dependency.

Philosophy. monero.fail's editorial differentiator is infrastructure-monitoring-as-public-good. The Monero community's privacy promise depends on a healthy distributed remote-node ecosystem — if all the wallets default to one node, that node becomes a centralised observation point. monero.fail keeps the distributed-node ecosystem visible: which nodes are up, which are stable, which are operator-published vs anonymous, which are Tor-only. By publishing this data in an API, monero.fail lets wallet developers route around the centralisation pressure that would otherwise build up by default. The service operates as community infrastructure: low-profile, donate-supported, not commercialised, doesn't try to be more than what it is.

Grade rationale. Grade A and editor's pick reflect: years of operational continuity as the reference node monitor; community-trusted source for the Monero node list; integrated by multiple wallets (Feather, Monerujo) as the default node-discovery source; published JSON API enabling downstream consumers; Tor onion mirror operator-published; no-JS web access; no commercial conflicts of interest; consistent inclusion in privacy + Monero infrastructure references. Last verified 2026-05-13.

Useful when. You're setting up Monero GUI / Monerujo / Cake Wallet / Feather and need to pick a remote node — monero.fail's sorted list with uptime is the right starting point. You're building a Monero-aware tool and need a programmatic node list — `/nodes.json` is the API. You want to operate via Tor and need an `.onion` Monero node — filter monero.fail's list by Tor transport. You're verifying that the node you're using is operator-published vs anonymous-submitted — monero.fail tracks that distinction. You're a node operator and want to verify your node appears in the public list and reports correct uptime.

Caveats. Uptime ≠ trust — a node being "up" with 100% uptime doesn't mean the operator is trustworthy. monero.fail measures liveness, not honesty. For high-threat use, run your own monerod and point your wallet at localhost — that's the only way to eliminate node-operator observation entirely. Probe blind spots — monero.fail probes the public node-list it knows about; private or recently-added nodes may not be tracked yet. Listing implies neither vetting nor endorsement — monero.fail tracks what exists, not what's recommended. The decision to trust a specific node operator is yours. Operator-published vs anonymous-submitted — both are tracked but the operator-published flag is the stronger signal; prefer those when picking a node. No native Monero node operations — monero.fail is a monitor; it doesn't run nodes itself, doesn't proxy your wallet traffic, doesn't broker queries. Your wallet still connects directly to whichever node you choose. JSON API rate limits — light limits exist; hammer the API and you'll be throttled. Consumers should cache the node list, not re-request on every wallet open.