Live network outages, your own connection, and your squad. Drag to move, scroll to zoom.
Don't have their code?
Enough to tell you whether their provider is down — but they can't be ranked as a host until they run a check.
Anything you set here is a claim, not a measurement. Your code will say so, and whoever pastes it will see that.
All of this is measured to the nearest Cloudflare edge rather than to the server hosting your match, so treat it as a strong indicator rather than a netgraph.
Most lag has one of two causes, and they need opposite fixes. Either something on the way out of your house is delaying your traffic, or the service you are trying to reach is having a bad day. A speed test answers neither question: a gigabit line can feel unplayable, and a service can be down while your connection is flawless. lagcheck measures your own line and reads the game's own status feed at the same time, then tells you which side the problem is on.
Idle latency — your round trip to the nearest edge with nothing else running. Mostly a fact about geography.
Latency under load — the same round trip measured while your upload is saturated. This is bufferbloat, and it is the usual reason a fast connection still feels terrible: your router queues packets behind a big transfer and everything you send waits its turn. A line that idles at 20 ms and goes to 400 ms under load will lose you fights, and a speed test will call it excellent.
Jitter — how much the round trip swings between samples. Games predict where you will be; jitter breaks the prediction, which is why a high-jitter line feels worse than a slower steady one.
Upload — graded against 10 Mbps: two 1080p video calls with a cloud sync running. That reference is deliberate. A single call is about 3.8 Mbps by Zoom's own figures, which is a floor rather than a standard — against it, an 11 Mbps line scores an A, and in 2026 it should not. Counting people does not work either: a television streaming a show and two tablets playing video use almost no upload at all, and gameplay is around 1 Mbps. What actually stacks up on the upload side is a short list — video calls, cloud sync, security cameras, livestreaming — so the reference counts those rather than heads. As a cross-check, the FCC's household benchmark of 20 Mbps up lands at a B.
Hosting is a different question and gets a different answer, in the group panel: there, upload is measured against what your actual group and game demand, because a line that is ample for your own use can still be short of carrying eleven other people.
Packet loss — the share of packets that never arrive. Graded against two published figures rather than a feeling: ITU-T Y.1541 puts the loss ratio for its most demanding traffic class, the real-time interactive one whose examples are voice and video calls, below one packet in a thousand, and that is where an A begins here. Cisco's enterprise design guidance for interactive voice allows 1%, and 1% is a C — scraping through, no headroom. Where the count is small enough that we cannot tell a fault from luck, the grade is taken from the least loss consistent with what we saw, so a single unlucky packet never costs anyone a letter. The percentage shown is always the one we measured.
Those five give one score out of 100 and a letter, and the score is simply the worst of them. A connection behaves like a chain: one bad property ruins the experience whatever the other four are doing, and improving anything except the bottleneck changes nothing you can feel. An average would say otherwise and teach you to fix the wrong thing. The letter is a band of the number rather than a second opinion about it, and where two measurements are close enough that neither is really the culprit, we say so instead of picking one.
If packet loss could not be measured — some networks block UDP, and without it a browser is blind to loss — the score is worked out from the other four and labelled a ceiling, because a shorter chain can only ever come out stronger. It is not quietly presented as the same number a complete check produces.
The result is laid out as a path: you to your router, your line to the edge, the edge to the game, and inside the game itself. Each segment says how we know — measured here, reported by the vendor, or not visible at all. A browser cannot see inside your house, so that first segment stays grey rather than being quietly coloured in.
Your network is matched against a live feed of networks currently in outage worldwide, by the number that identifies your provider. If your ISP is the one on fire, you will be told, and no amount of restarting your router will help.
For a peer-hosted session the right host is not whoever pays for the fastest plan. It is whoever's worst connection to anyone else in the group is least bad — geography and upload decide that, not advertised speed. Everyone runs the check, shares a short code, and the group is ranked. The codes are pasted by hand on purpose: nothing about anyone is uploaded, and there is no account and no group stored on a server.
The check measures to a nearby edge, not to the specific server hosting your match, and the latency and upload figures come from timed HTTP requests rather than from the UDP traffic a game actually sends. Packet loss is the exception: it is measured over real UDP through a relay, because there is no other way for a browser to see a dropped packet at all — and on a network that blocks UDP we report it as not measured rather than as zero. Those limits are stated here rather than papered over. More about how this works, or read the privacy page.