For users searching specifically for the monitor configuration: cadence, vantage, retry policy, and what counts as up versus degraded versus down.
Probe cadence: 60 seconds per cycle. Vantage: a small set of dedicated probe nodes spread across multiple regions, each running its own Tor client with circuit isolation per probe. Retry policy: a failed probe attempt is retried once on a fresh circuit before being recorded as a failure for the cycle. Up: HTTP response received within the 60-second probe budget. Degraded: response received but p50 latency above 250 ms over a rolling 5-minute window. Down: no response or timeout, both attempts.
The probe is hand-rolled, not a third-party SaaS. Source code for the probe is available under the project repository; reproducibility is a project value rather than an aspiration.
Builds a route to each address, requests a page, records whether it answered and how long it took, then discards the route so the next pass measures a fresh path rather than a warm one. Reusing a good circuit would report flattering numbers that nobody experiences.
A warm connection is fast and a cold one is not, and users almost always arrive cold. Measuring warm would produce a page whose numbers never match anybody's experience, which is worse than no page at all.
Less often than the noise suggests. Individual passes vary a lot because relay conditions vary a lot. A state worth reporting is one that persists across passes, which is why a single failed check does not move anything on the board.
That the result generalises to your connection. It is one observer with one set of routes. Read it as evidence that a path exists rather than as a promise that yours will work, and it stays useful without being misleading.
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.