How Oniongate Measures Onion Status: Probe Loop, Cadence and Uptime Math (2026)

The oniongate probe loop

A worker opens a connection to each monitored endpoint over Tor and requests a small, known resource. It records three things: whether the request completed, how long the round trip took, and the moment the check ran. That record is the only input to a status. There is no editorial judgement layered on top.

Every endpoint is checked on its own short loop, roughly every few seconds. Because each mirror is probed separately, one dead address does not drag a healthy service into a false red on oniongate, and one lucky address does not hide a wider outage. The service-level banner oniongate shows is a summary of its endpoints, not a substitute for them.

What oniongate's status words mean

Oniongate uses four words, and only four. Each one carries a fixed meaning so that a reading is never ambiguous.

How oniongate computes latency and uptime

Latency is the round-trip time of a successful probe, in milliseconds, shown as a tabular number so columns line up. Tor adds real overhead, so a few hundred milliseconds is normal and not a fault. Oniongate reports the median of recent successful checks rather than a single sample, which keeps one slow circuit from dominating the figure.

Uptime is the share of checks that succeeded over a window. Oniongate rolls it up over the last 24 hours, 7 days and 30 days. A check that never ran does not count as a success or a failure, it simply is not in the sample, which is why a brand-new endpoint shows blank on oniongate rather than a suspiciously perfect score.

What oniongate does not do

Oniongate does not rank services, and it does not sell placement. Oniongate does not judge what any onion market is for. Oniongate does not mint onion addresses either. The addresses oniongate probes come from a signed directory that publishes them under a 2-of-3 quorum, and oniongate only annotates that list with live measurements. Any address you find outside the signed list is not one oniongate publishes, and treating it as ours is how phishing works.

Oniongate is a mirror of reality, held as close to the present as a probe loop allows. When oniongate is wrong, it is because a measurement was wrong, and the fix on oniongate is a better measurement, never a nicer-looking number.

Edge cases the probe loop has to handle

A probe loop that only ever describes the easy case — request sent, response received — is hiding most of what actually happens measuring services over Tor. Here is how oniongate's loop handles the messier cases.

A response arrives, but after the timeout window

A late response is treated as a miss for that cycle, not as a slow success. The timeout exists because a page that eventually loads after twenty seconds is not the same experience as one that loads in two, and conflating the two would make the latency figures oniongate publishes meaningless. The next cycle gets a fresh chance to record a clean answer.

The circuit builds but the destination returns an error page

oniongate's probe checks that a valid HTTP response came back within the timeout — it does not currently parse page content to distinguish a normal page from an error page served by the destination itself. This is a deliberate scope limit: content-aware probing adds fragility and false signals of its own, and reachability is the narrower, more reliably measurable claim this project is built to make.

Multiple mirrors disagree in the same cycle

When one mirror for a service reads reachable and another reads down in the same cycle, both readings stand independently on that service's status page rather than being averaged into one number. A visitor deciding which address to use benefits more from seeing the actual split than from a blended figure that hides which specific mirror is the problem.

Methodology questions, answered directly

Does a human ever type in a status by hand?

No. The only input to a status word is the automated probe record: whether the request completed, how long it took, and when it ran. There is no editorial step between a measurement and a tile.

Why does one dead mirror not turn a whole service red?

Because each endpoint for a service is probed on its own separate loop. A service-level summary is built from its individual endpoints, not from a single shared check, so one unreachable mirror does not falsely mark a service that has other working mirrors, and one lucky mirror cannot mask a wider outage either.

Where do the addresses being probed actually come from?

From a signed directory published under a 2-of-3 quorum, never minted or guessed by oniongate itself. If you find an address claiming to be monitored here that is not in that signed list, it is not ours, and treating an unverified address as if it came from this site is exactly how a phishing clone operates.

What happens when a measurement turns out to be wrong?

The fix is always a better measurement, never a cosmetic correction to make a number look better. The board is meant to mirror reality as closely as an automated probe loop over Tor allows, and when it drifts from reality the response is to improve the probe, not to touch the displayed figure directly.

A worked example: turning raw probes into a 24h uptime figure

The uptime percentage shown on a status page is not a single measurement — it is a rollup of many individual probe results, and seeing one worked example end to end makes the arithmetic concrete instead of abstract.

The raw log for one onion address, one day

Say the probe loop for a given onion address runs on its normal cadence across a 24 hour window and produces 96 individual attempts. Of those, 91 complete within the timeout and count as successes, 3 time out and count as failures, and 2 never fire because the probe worker itself was mid-restart during a deploy — those 2 do not count as either success or failure, they simply are not in the sample. The 24h figure shown is 91 divided by 94, not 91 divided by 96, because a probe that never ran cannot honestly be counted as a miss against the endpoint.

Why the missing-probe distinction matters

Folding a worker outage into the failure count would make oniongate's own infrastructure problems look like the monitored service's problem, which is exactly backwards. An onion address that was perfectly reachable the entire time our probe worker was down should not see its uptime figure punished for our downtime. Excluding those cycles from the denominator, rather than counting them as failures, is a small design choice that has an outsized effect on whether the published number reflects the service or reflects us.

Why 24h, 7d and 30d can tell different stories

A service that had one bad hour today but has been rock solid for a month will show a noticeably lower 24h figure than its 7d or 30d figure, and that divergence is informative rather than a bug. Reading only the 24h number after a rough hour makes a generally reliable onion address look shaky; reading only the 30d number can smooth over a genuine ongoing problem that only started recently. The three windows exist side by side specifically so a visitor is not stuck choosing one timeframe that happens to tell a flattering or unflattering story.

How oniongate chooses its probe cadence

The interval between checks is a trade-off, not an arbitrary number. Probing too rarely means a status can be stale for hours before oniongate reflects reality, which defeats the point of a live board. Probing too aggressively adds unnecessary load to onion services that have no obligation to serve automated traffic quickly, and it increases the odds that Tor's own circuit variability — not anything wrong with the destination — produces a noisy, flickering reading that is technically more frequent but less trustworthy.

oniongate's cadence sits deliberately in between: frequent enough that a real outage shows up within a bounded, predictable window, infrequent enough that a single slow circuit does not get mistaken for a pattern. When a reading looks wrong, the first thing worth checking is whether it is an isolated miss inside that window or a repeated failure across several consecutive cycles — the changelog and per-cycle history on each status page make that distinction visible instead of collapsing everything into one tile.

The oniongate check, spelled out as four steps

Every reading on oniongate, for every onion market it tracks, reduces to the same four-step procedure. Nothing about a single service gets a shortcut through fewer steps or a hand-set exception.

1. Open a circuit to the listed onion address. The probe worker builds a fresh connection over Tor to one specific endpoint from the signed directory, the same way any Tor Browser session would, not through a shortcut or a cached path.
2. Request a small, known resource and start the clock. The request is deliberately lightweight so the timing reflects network and circuit conditions rather than the destination rendering a heavy page.
3. Record success, failure, or timeout, with the elapsed time. A completed response within the timeout window is a success; anything else — connection refused, timed out, circuit failed to build — is recorded as a failure for that one cycle, for that one endpoint only.
4. Roll the result into the service's status word and uptime windows. The single-cycle result feeds the 24h/7d/30d rollups and, combined with every other endpoint for that market, decides whether the service-level banner reads Online, Checking, Down or Unknown.

That is the entire method. There is no fifth step where a person looks at the output and decides whether to publish it — the four steps above are the whole of what oniongate does before a reading appears on a status page.

Verifying oniongate's method independently, not just trusting this page

A methodology page is easy to write and hard to prove from inside the site describing it. Rather than asking a reader to take oniongate's word for how Tor reachability checking works in general, this section points outward.

How Tor circuits and .onion addresses actually work

The mechanics behind why a probe over Tor takes longer than a plain web request, and why a circuit can fail without the destination being down, are documented directly by the Tor Project rather than paraphrased secondhand here. Reading their own onion services documentation is a better way to judge whether oniongate's probe design makes sense than trusting a status board's self-description alone.

Operational security beyond what a status page can cover

Oniongate's scope stops at reachability. For the wider set of habits — browser hardening, metadata hygiene, safe communication — the EFF's Surveillance Self-Defense guide is a maintained, independent reference that goes well beyond what any single onion-market status board should attempt to cover.

Running your own reachability check

Nothing about oniongate's method requires trusting oniongate specifically. A visitor with Tor installed can open the same onion address directly and see whether it loads, which is the manual version of exactly what the probe loop automates on a schedule. Projects like OnionShare are a useful reference for how independent, security-reviewed tooling around onion services is typically built and documented, for anyone who wants a second frame of reference beyond this one page.

Why this methodology applies identically to every darknet market oniongate tracks

A probe method that changes shape depending on which onion market it is checking would be a much weaker claim than the one this page describes, so it is worth stating plainly that it does not.

One Tor probe loop, seven darknet markets

Every darknet market on the oniongate board — torzon, mars, wethenorth, nexus, vortex, omega and drughub — is measured by the same probe loop over Tor, on the same cadence, scored by the same four status words. A market with five onion mirrors is not treated more leniently than a market with one; each mirror, for every market, is an independent probe target with its own timeout and its own retry logic.

Why cross-market consistency matters more than any single reading

A status board loses its value the moment one darknet market gets a gentler check than another. If a probe timeout, a retry count, or a "how many misses before Down" threshold ever differed market to market on oniongate, a reader would have no way to compare two onion markets' status honestly — a longer green streak might just mean a looser method, not a more reliable market. Holding the method fixed across every tracked market, including any darknet market added later, is what makes a cross-market comparison on oniongate meaningful instead of decorative.

How an onion market's own mirror count changes what gets probed, not how

Some onion markets on oniongate publish a single onion address; others, like torzon and mars, publish five. The method itself does not bend to accommodate either shape — a market with five mirrors simply means five independent Tor probe targets instead of one, each still judged by the identical timeout, retry, and status-word rules as any other onion address on the board. A market's mirror count is the operator's own redundancy decision, not a variable oniongate's methodology adjusts for.