Tracker Jitter: Why Uptime Dashboards Disagree About the Same Market

Two uptime dashboards both claim to track the same onion service. One says 94% availability over the last week. The other says 71%. Neither is lying, exactly. They’re measuring different things, sampling at different intervals, and in some cases polling from infrastructure that gets treated differently by the market’s own anti-DDoS layer. If you’ve spent any time cross-referencing darknet market status pages, you’ve seen this. It’s not a bug in any single tracker. It’s a structural property of how these services are monitored.

This piece is research only. No live links, no access instructions. The goal is to explain why the numbers disagree, and what that disagreement actually tells you.

Availability is not one number

An onion service is reachable or it isn’t. That sounds binary. It isn’t.

When a tracker polls a .onion address, the request has to traverse Tor, hit the market’s hidden service descriptor, get routed to an introduction point, and complete a rendezvous. Any of those steps can fail independently. A timeout at the rendezvous stage looks identical to a dead service from the tracker’s perspective. So does a rate-limited response from the market’s reverse proxy.

This matters because bulletproof hosting providers, which form the bedrock of dark web operations according to SOS Intel’s analysis of the underground services economy, are explicitly designed to absorb and deflect abuse traffic. That same infrastructure sometimes treats aggressive polling from known tracker IP ranges as hostile. The tracker logs a failure. The market was fine. The number drops.

This is the first and most common source of tracker jitter: false negatives from defensive infrastructure. It’s also the hardest to detect from the outside, because the tracker has no way to distinguish “service is down” from “service is refusing me specifically.”

Sampling intervals hide different things

Most trackers poll on a fixed schedule. Five minutes is common. Fifteen minutes is also common. The difference is enormous.

A market that goes down for eight minutes every hour for maintenance will show roughly 87% uptime at five-minute polling and roughly 73% at fifteen-minute polling, depending on phase alignment. Same market. Same outages. Wildly different scores.

There’s a second problem. Short outages get smoothed. A service that’s flapping, up for two minutes, down for three, up again, can look stable at coarse intervals because the poll happens to land during the up windows. The dashboard says 99%. Users can’t load the page half the time.

I’ve seen trackers that report a market as “up” based on a single successful TCP handshake to an introduction point. That tells you almost nothing about whether the market’s HTTP layer is serving pages. Yet it gets folded into the same uptime percentage as a full end-to-end check.

The copycat and rebrand problem

Here’s where it gets philosophically messy.

When a market goes offline and a successor appears with similar branding, trackers have to decide whether that’s the same service continued or a new one. SOS Intel’s ransomware victim analysis makes this explicit for a different domain: stripping out rebrands, copycats, fabricated claims, and shared-affiliate cases left them with 132 companies that had no verifiable link, and even that figure is described as an upper bound rather than a confirmed count.

The same logic applies to markets. Two trackers can look at the same *.onion rotation and disagree on whether it’s continuity or a fresh operation. One tracker carries the uptime history forward. The other starts from zero. Now you have two dashboards reporting on what is nominally “the same market” with completely different historical baselines.

Affiliate and mirror structures make this worse. A market operating multiple onion addresses, some mirrors, some load-balanced entry points, will show different availability per address. A tracker that polls one address sees a partial picture. A tracker that polls all of them and averages will report a number that corresponds to no single user’s experience.

What TRM’s methodology tells us by analogy

TRM Labs’ crypto adoption work offers a useful parallel. When they build a composite index, they combine on-chain volumes, web traffic attribution, and GDP-per-capita scaling into a single score. Each input has known limitations. On-chain data doesn’t reveal user location, so they use web traffic as a proxy. Raw volumes overstate adoption in wealthy economies, so they scale by purchasing power parity.

Every adjustment is a judgment call. Stack enough judgment calls and you have a number that’s defensible but not uniquely correct. Another team making different reasonable choices would produce a different number.

Uptime dashboards work the same way. The composite score at the top is an editorial artifact, not a measurement. The underlying raw data might be identical between two trackers. The scores won’t be.

What trackers are actually good for

Not prediction. Not trust scoring.

They’re useful as a rough signal that something changed. If three independent trackers all show a market dropping from their respective baselines at the same time, that’s real. If one shows a drop and two don’t, it’s probably a polling artifact or a targeted block.

The reverse also holds. A market that’s been consistently reachable across multiple trackers over weeks is probably stable infrastructure. A market that appears on one tracker as 99% and on another as 60% is telling you something about its mirror setup or its DDoS posture, not about its reliability.

TRM’s alert-triage workflow for analysts is instructive here. The first step isn’t “is this alert real.” It’s prioritization, context assembly, exposure path tracing. The analyst’s judgment comes after the data is structured, not before. Trackers give you structured data. They don’t give you judgment.

Practical notes for researchers

• Check the polling interval. If it’s not published, that’s a red flag. A tracker that won’t tell you how often it checks is hiding something, usually that the interval is too coarse to be useful.
• Look for multiple check types. A single TCP check is noise. A combination of TCP, descriptor fetch, and HTTP layer verification is more meaningful, though still imperfect.
• Cross-reference at least three sources. Two trackers disagreeing is normal. Three disagreeing consistently over time tells you the market’s infrastructure is unstable or its mirrors are inconsistent.
• Watch for history resets. If a tracker’s uptime percentage suddenly jumps after a .onion rotation, they probably started a new counter. That’s not the same market anymore.
• Ignore “security scores” and “trust ratings” unless the tracker publishes its methodology. These are almost always editorial.

The AnySign4PC zero-day coverage from earlier this year is a useful reminder of how much defenders rely on trusted infrastructure behaving predictably. A widely installed financial security product became the infection path because users trusted it. Uptime dashboards occupy similar territory in the darknet research space. They look authoritative. They have clean UIs. And most of them are computing numbers that don’t mean what their users think they mean.

That’s not a reason to ignore them. It’s a reason to read them as one input among several, not a verdict. The number at the top is someone’s opinion rendered in decimal form. The raw poll log, if you can get it, is closer to truth. Most trackers don’t show you the raw log.

Which is, if you think about it, exactly the kind of opacity you’d expect from a market that wants its downtime quietly smoothed over by third-party monitors.