HERMES: Finding Where the Internet Slows Down, Using Public Speed Tests

We have covered Measurement Lab (M-Lab) on this blog before: how its NDT speed test works, how it compares with Ookla and Fast.com, its newer MSAK framework and the Internet Quality Barometer. Those posts were about measuring one connection. HERMES combines billions of them. It watches M-Lab’s public data for groups of users whose performance suddenly drops and points to the part of the network most likely responsible.

What HERMES is and where it came from

HERMES looks for the slowdowns that make video calls and games painful even while a network is still up.

The project is a collaboration between Columbia University, LIX-CNRS, Northeastern University and Google. M-Lab says HERMES has been running since August 2024, and the full method was published at ACM SIGCOMM 2026 in Denver (August 17–21).

The full paper is open access. The idea behind it is simple. NDT runs about 4 million times a day, and every result is published along with a traceroute. Over five months, HERMES processed 4 billion tests and found 65,000 events in 166 countries, only 5.2% of which other public observatories caught. The code, the BigQuery dataset and a dashboard are all public.

How HERMES works

HERMES doesn’t trust any single speed test, since one slow result could just be bad Wi-Fi. Here is what it does instead.

  1. It groups tests by access network, metro area and M-Lab server, and keeps only groups with enough tests from enough distinct users.
  2. It compares each day with that group’s previous week, using statistical tests on latency and throughput. Only shifts that are significant, widespread and in the bad direction get flagged.
  3. It maps the paths. Each test comes with a traceroute from the server to the user, and a share of tests (now 50%) also get a reverse traceroute from the user back. Every hop is tagged with its AS, IXP and city.
  4. It localizes the cause by looking for what changed on the degraded paths (a reroute) or what they have in common that healthy paths don’t (congestion). Each event ends up labeled localized, ambiguous or unresolved.

The reverse path turns out to matter a lot. In the paper, half of the links implicated in events were visible only in that direction.

What sets HERMES apart

Most public observatories watch for networks going dark. Cloudflare Radar spots outages from traffic volumes but doesn’t expose the paths needed to locate a slowdown, and IODA tracks reachability rather than performance. Private systems like Microsoft’s BlameIt do see performance, but only toward their own services, and their data is closed. HERMES is open, measures what users actually experience, and looks at both path directions. In the paper it surfaced more than 11 times as many publicly reported events as existing public observatories, and agreed with a cloud provider’s monitoring on the problem segment 94.5% of the time.

Case study: the Indianapolis server event, October 2026

In mid-October 2026, HERMES spotted a problem at the server end that showed up as thousands of slow speed tests. Events on paths to M-Lab’s Indianapolis server (ind23372, hosted by AS23372) jumped from about 78 a day to 2,622 over October 16 to 18.

HERMES dashboard, Population View filtered to Server ASN 23372, Oct 10–19, 2026 · read Oct 20

Users of AT&T, Spectrum, Charter, Comcast and others across the Midwest and Southeast saw uploads collapse, by 95% for one set of 71 client groups on October 17, while downloads held. Taken one at a time, each result would have blamed the user’s ISP. HERMES instead traced the shared segment to the hosting network and the Cogent and Hurricane Electric transit links into it in Chicago and Indianapolis. So a user who got a bad NDT result that week most likely had a working connection, and the slow result came from the path to the test server.

Reading HERMES responsibly

The authors are upfront about HERMES’s limits. Speed tests are user-initiated, so the sample skews toward people who already suspect a problem. Results are daily, so short blips can be missed, and HERMES only sees paths toward M-Lab servers. And when it names a network, that is a statistical association, so proving the cause still takes more evidence.

Why this matters for network teams

HERMES gives network teams a public, path-aware record of when users’ performance got worse and where, useful for escalations and postmortems. It complements synthetic monitoring like NetBeez, which tests from your own sites to the services you care about on a fixed schedule. Used together, they help you tell whether a problem is in your own network, your provider’s or the wider Internet. Organizations can also extend what HERMES sees by hosting an M-Lab server.

decoration image

Get your free trial now

Monitor your network from the user perspective

You can share

Twitter Linkedin Facebook

Let's keep in touch

decoration image