The p50 / p95 latency profile across all three production mirrors, sampled across fresh Tor circuits over the past 24 hours.
Median platform-level p50: 141 ms. The headline mirror leads at roughly 108 ms p50 with a 214 ms p95; backup A sits at 141 ms p50 with 267 ms p95; backup B sits at 287 ms p50 with 612 ms p95 (degraded-mode classification). All three numbers are sampled across fresh Tor circuits, not from a steady-state pool, so they reflect a worst-case-realistic profile rather than warm-cache best-case.
What changes the numbers: Tor guard rotation on the platform side, congestion in the broader Tor network, and the time of day (latency rises during European-evening peak). The numbers above are 24-hour aggregates; the homepage panel shows the most recent cycle's figures.
A connection crosses roughly six relays before a byte comes back, and there is no cache anywhere in the chain. The slowest relay in the path sets the pace for everyone. Slowness here is the architecture working rather than a fault to be fixed.
The first page of a session pays for the descriptor lookup and both halves of the rendezvous, which is tens of seconds. Every page after it reuses that work and arrives in a few. This single fact changes how to use the service: one long session beats four short visits by a wide margin.
A good median with a bad tail is the pattern behind pages that feel fine and then randomly hang. The median describes the typical request and the tail describes the ones you remember.
Over two minutes on a cold load, or a warm page taking more than half a minute. Request a new circuit for the site, and if a second draw is just as slow, another mirror will be quicker. Below those thresholds, waiting is the correct move.
Component states, the 90 day uptime history and the incident log live on the status dashboard. This page covers one question in depth rather than repeating the board.