LIVE MONITOR

The main instrument. It streams real data between your browser and Cloudflare's edge network continuously, sampling throughput every 100 milliseconds and firing a tiny latency probe every second. A one-off speed test answers "how fast is my line right now?" — the Live Monitor answers a harder and more useful question: "what does my connection do over time, and does it ever fail?" Intermittent faults — the video call that drops twice an evening, the game that rubber-bands every few minutes — are invisible to one-shot tests, because the odds of a ten-second test overlapping a ten-second fault are terrible. Run the monitor for 15 minutes or 24 hours and the fault has nowhere to hide.

To prove (or disprove) an intermittent problem; to measure sustained real-world speed rather than a burst; to watch stability while you change something (move the router, switch Wi-Fi channel, toggle a setting); to collect evidence an ISP can't wave away.

1. Pick a duration and intensity in Settings (or just press START — 15 minutes of CRUISE is the default).
2. Leave it running. Use your connection normally, or don't — both are informative.
3. PAUSE freezes the test; STOP ends it. Pressing START after a stop clears the last run and begins fresh.
4. When the timer completes you get a report you can download.

Download / Upload cards. What flowed in the last instant, with totals underneath. Important: in CRUISE mode the monitor deliberately trickles (a light ~4 Mbps stream) and only opens the throttle for a ~12-second burst every three minutes — so the cruise average is not your line speed; the peak is much closer. FULL BURN saturates continuously, so its average is your sustained line rate.

Latency & jitter. Latency is the round trip to the edge; the minimum is the physics-and-infrastructure floor of your connection (fibre typically sits under ~10 ms to a nearby edge, cable/VDSL 10–25 ms, 4G/5G and satellite higher). Jitter is how much that wobbles — the number that actually predicts choppy calls. On a healthy wired path, jitter stays below roughly 15% of latency; jitter approaching or exceeding latency means queueing or radio interference close to you.

Packet loss. Counted on the once-per-second probe stream. Zero is normal. A few hundredths of a percent is noise; sustained loss of 1%+ degrades everything and points at an impaired line or chronic congestion.

Connection stability. A rolling per-second score summarised as a percentage and a verdict (99.5%+ EXCEPTIONAL, 98%+ GOOD, 95%+ FAIR, below that DEGRADED). It is driven mostly by probe loss and latency spikes — which means a collapsed download with clean probes barely dents it. That's deliberate honesty, not a bug: dropouts are counted and reported separately, and the report will tell you when the headline number understates the story.

Throughput chart. The whole test at a glance. FULL shows the entire planned duration; 15M/10M/5M/1M zoom to a trailing window. Red dashed verticals mark the exact moment each dropout was detected — if they line up evenly, that regularity is itself a diagnosis (see Dropouts below).

The observatory log. The plain-English narration: test started, bursts, dropouts with probe results, report ready. When something odd happens, the log is the first place to look.

DROPOUTS & THE PROBE BATTERY

"The internet dropped" almost never means everything died. Usually one layer failed — the Wi-Fi radio, the DNS resolver, one route, or just the single TCP flow carrying your download — while everything else kept working. The difference matters enormously, because each failure pattern has a different culprit and a different fix. Relay99's answer is the probe battery: the instant sustained throughput collapses against its recent baseline, the monitor fires seven independent probes at every network layer it can reach — while the hole is still open — and records which survived.

The seven probes: EDGE RTT (the existing warm connection — is the path itself alive?) · NEW TCP+TLS (can a brand-new connection be established?) · CDN PATH (a second, independent provider — is it just one network?) · DoH GOOGLE and DoH CLOUDFLARE (encrypted DNS, two providers) · YOUR RESOLVER (a forced cold lookup through your own DNS) · UPLOAD LANE (does sending still work?).

The pattern of survivors is a fingerprint. It converts "it broke again" into "this specific layer broke while these five didn't" — which is the difference between guessing and diagnosing.

1. Nothing — it's automatic. Every dropout is logged, marked on the chart, and dissected in the results.

All probes green is the most counter-intuitive and most common pattern: the link never dropped — something killed your specific transfer flow while letting everything new through. That points at per-flow state on the path (router NAT/flow-offload tables, an ISP traffic shaper, carrier-grade NAT), not at your line. All probes red is a genuine link-level outage: line, modem, or radio. DNS-only failures implicate resolvers, not connectivity. New-connections-fail while the warm connection survives is the classic full NAT table. Upload-only failures point at upstream impairment (on cable, the modem's upstream RF).

Spacing is evidence too. Random congestion doesn't keep time. Dropouts recurring on a tight interval mean a timed process: ~60 s intervals smell of Wi-Fi background scans, the five-minute family belongs to NAT/CGNAT table sweeps and short DHCP renewals, and hourly patterns match PPPoE/session re-authentication. The report does this matching for you.

One honest caveat: in CRUISE mode a dropout that opens right after a line-rate burst can show an inflated duration (the detector waits for a recovery threshold the light cruise stream can't reach until the next burst). The report flags exactly which durations to read as upper bounds.

REPORTS & ROOT-CAUSE ANALYSIS

Every completed (or stopped) test produces a report card — downloadable as a PNG image, an SVG, or, most usefully, a self-contained HTML file. The HTML report carries everything: the headline numbers, the full throughput chart with dropout markers, the complete forensics list for every dropout, and a rule-based root-cause analysis written by a network-engineering rule engine that reasons only from this test's measurements — which layers died together, how events were spaced, what the instrument itself was doing at the time.

To get a ranked list of likely causes with concrete fix instructions instead of a folklore checklist; to hand your ISP evidence with timestamps they can check against their own logs; to keep before/after proof when you change something.

1. Let a test finish (or STOP it) — the TEST COMPLETE panel appears.
2. Press DOWNLOAD HTML for the full report; PNG/SVG for a shareable card.
3. Open the HTML file in any browser — it works offline and prints cleanly.

Findings are tagged: FINDING (something wrong, earned by the data), OBSERVATION (context), INSTRUMENT NOTE (the engine correcting for its own artifacts or critiquing its own headline verdict — when the tool might mislead you, it says so). Ranked causes carry a percentage that is relative evidence weight among the candidates, not absolute certainty — 56% doesn't mean "56% chance", it means "over half the evidence points here". Each cause lists evidence for (▲) and against (▽), and ships a numbered HOW TO FIX IT plan with the exact router menu names, numbers computed from your own measurements, and word-for-word scripts for ISP calls.

The DISCRIMINATING TESTS are the most valuable part. Each one is chosen because its outcome splits the top candidates — run them in order and you converge on the true cause in one or two tests instead of thrashing through settings.

TEST SETTINGS

Four decisions shape a test: endpoint (leave on Automatic to use the nearest Cloudflare edge — choosing a distant one measures the internet between, which is occasionally exactly what you want), duration (1 minute to 24 hours), intensity, and an optional data cap.

CRUISE is the observatory mode: a light steady stream (~4 Mbps) with a line-rate burst every three minutes to refresh the peak reading. It's designed to run all day without eating your allowance or your bandwidth — think of it as leaving a seismograph running. FULL BURN saturates the line continuously with parallel streams: it measures true sustained throughput and exposes load-dependent faults (bufferbloat, overheating hardware, shapers that punish sustained flows) that cruise is too polite to trigger. Burn is also the honest test of "what happens to my latency while I'm actually downloading?"

1. Hunting an intermittent fault? CRUISE, long duration (2–24 h), covering the time of day it bites.
2. Measuring speed or diagnosing under-load problems? FULL BURN, 15 minutes.
3. On a metered connection? Set a DATA CAP — the test stops itself at the limit.

Burn moves data at line rate for the whole duration: on a 500 Mbps line that's roughly 3.7 GB per minute, over 5 TB if you left it running 24 hours. The estimate panel in Settings does this arithmetic for your line before you commit; a 24-hour burn is almost never what you want — that's what cruise is for.

NAME SERVERS (ROUTE99)

An audit of a domain's DNS infrastructure, run from your browser. Where the DNS Test (below) asks "which resolver should I use?", Route99 asks "is this domain's DNS healthy?" — the question that matters when you own or manage a domain, or when one particular site misbehaves. It measures resolver response for the domain (including a forced cache-miss "cold" lookup through your own resolver), checks DNSSEC end-to-end (validation flag, DS record at the registry, DNSKEY in the zone), polls a panel of public resolvers for consensus on the answer, walks the delegation chain (root → TLD → authoritative nameserver → address), and lists the domain's records.

After changing DNS records or nameservers (did it propagate? is the delegation intact?); to verify DNSSEC actually validates; when a site works on one network but not another (consensus reveals split or filtered answers); to see TTLs before planning a migration.

1. Type a domain (default: relay99.com) and press RUN AUDIT.
2. START MONITOR re-runs the audit on an interval — useful while waiting for a change to propagate.

Resolver speed: the cold number is the honest one — it's a lookup nobody has cached, the cost a first-time visitor pays. Warm lookups mostly measure your resolver's cache. DNSSEC: a closed lock means responses are cryptographically validated end-to-end; an open lock usually means the zone simply isn't signed — extremely common, not an emergency, but unsigned zones have no tamper-proofing. A broken chain (signed but failing validation) is serious: some resolvers will refuse to resolve the domain at all. Consensus: all resolvers agreeing is the healthy norm. Divergence has two readings — a CDN serving different addresses per region (fine, by design) or a resolver being filtered/hijacked (bad). If the odd answer out comes only from your own resolver, be suspicious of it, not the domain. Delegation: each hop must agree; TTLs tell you how long stale answers can linger after a change.

DNS TEST (RESOLVER BENCHMARK)

Every website visit starts with a DNS lookup, and that lookup goes to whichever resolver your device or router is configured to use. This test races ~20 public DNS-over-HTTPS resolvers from your browser, over your connection — which is the only measurement that matters, because anycast routing means the "fastest resolver" is different in London than in Lagos. Each resolver answers a mix of cached and deliberately-uncached queries; the ranking is built on the median (typical feel) and P95 (the bad moments — one slow lookup in twenty is what you actually notice).

Snappier browsing (resolver latency fronts every new connection); choosing a security- or family-filtering resolver with known cost; checking whether your ISP's default resolver is holding you back — the test highlights your current resolver in the ranking.

1. Pick a mode — QUICK for a fast look, STANDARD normally, THOROUGH for a decision.
2. Choose whether filtered resolvers join the ranking, then START.
3. Tap any row for that resolver's full timing detail.

Prefer consistency over the best headline: a resolver with median 12 ms / P95 18 ms beats one with median 9 ms / P95 90 ms in real use. Verified vs latency-only: solid chips are resolvers whose answers the test can cryptographically verify; dashed ones can only be timed — their numbers are real but treat them as timing-only. Don't switch on one run. Resolver performance shifts with time of day and network load — run the test a few times across a day or two before committing, then set the winner in your router's DNS settings (the HTML report's fix plans include the how-to). Filtering resolvers trade a little latency for protection; the ranking shows exactly how much you're paying.

OBSERVATORY

The fleet view: every completed Relay99 test anywhere contributes one anonymous record, and this page charts the aggregate — ratings, download/latency/stability distributions, most-tested endpoints, regional averages, and fleet-wide dropout statistics. Privacy is engineered in, not promised: the record is built server-side from region-level location only (no city), the IP address is never stored — it's converted to a one-way keyed hash so repeat sources can be counted but never identified — and the throughput history stays on your device.

Context. "Is 40 ms latency normal?" and "is everyone's Thursday evening this bad, or just mine?" are questions a single test can't answer. Comparing your report against the fleet's distributions tells you whether you're an outlier worth investigating.

1. Nothing to configure — contribution is automatic when a test completes.
2. Browse the charts; REFRESH pulls the latest aggregate.

The distributions are the useful part: find your own result's bucket in the download, latency and stability histograms — being in the worst bucket while your neighbours cluster higher is a signal your line, not the internet, deserves attention. The dropout panel shows what fraction of all tests catch dropouts and how many show the regular timed-process signature. Small-sample honesty: while the fleet is young, a handful of tests can swing the charts — read counts before conclusions.

COOKIES & PRIVACY (GDPR)

Relay99 uses exactly two cookies, and both are boring on purpose:

Both are first-party and contain no identifier of any kind — no user ID, no session token, nothing unique to you. There is no localStorage, no analytics, no ad-tech, no fingerprinting, and zero third-party cookies. Pure preference cookies like these fall under the ePrivacy "strictly necessary for the service you asked for" family — which is why there's no cookie banner: there is nothing to consent to.

Measurement traffic. Running a test necessarily sends data between your IP and the test endpoint (Cloudflare's edge), and the DNS benchmark, by its nature, contacts the resolver operators being raced — that is the service you explicitly requested. Hosting is served by Bunny.net (an EU company).

The Observatory record. When a test completes, one anonymous summary is contributed to the fleet dataset. Your IP address is never stored: the server keeps region-level location only (no city) and converts the IP into a one-way keyed hash so repeat sources can be counted but not identified. Full precision: under GDPR's strict definitions a keyed hash is pseudonymisation rather than anonymisation — which is why the rest of the record is minimised to nothing but test metrics.

Fonts. The Space Mono typeface is self-hosted on relay99.com — no third-party font requests, no IP shared with any font provider. The downloadable HTML report references the same relay99-hosted stylesheet and falls back to your system's monospace when opened offline.

Cookie-wise: fully compliant, banner-free by design. Data-wise: engineered for minimisation first — nothing is collected that the charts on the Observatory page don't visibly use, and nothing identifying is stored at all. This section is an engineer's transparency statement rather than formal legal advice; if you want zero contribution to the fleet dataset, switch it off under Settings → OBSERVATORY — with the toggle off, nothing is sent at all.