The other tools in the app
PulseLAN’s job is the device-to-device LAN speed test — that’s on the home page, and it’s what the app is for. These five tools sit around that measurement. They answer the follow-up questions a LAN number raises; none of them replace it.
All five run in the PulseLAN app — iOS, Android, Windows, and macOS. Each tool below repeats that in its own header, next to whether its traffic stays on your network.
They are not browser features, and that is a browser security boundary rather than something we haven’t got to yet. A page served over HTTPS is not permitted to reach local-network addresses, and no web page of any kind can open the raw TCP connections that device discovery, the ping monitor, and a device-to-device throughput test are built on. We would rather say that plainly than ship a web page that pretends to scan your LAN. The one measurement that needs no local-network access at all is an internet speed test, because it only ever talks to public endpoints — which makes it the only tool on this page that could be anything other than an app feature.
Internet speed test, with a bottleneck verdict
Measures download, upload, and latency against Cloudflare’s public speed-test endpoints. Then it does the part no internet speed test can do: it compares that result against a recent LAN result from the same network and says which side is the limiting factor — your Wi-Fi and wiring, or your ISP.
That comparison is the whole point. An internet speed test knows nothing about your LAN, and a LAN test knows nothing about your ISP, so neither one on its own can tell you where to spend your afternoon. PulseLAN holds both numbers, so it can answer the question you actually had: if your LAN throughput sits well below your internet throughput, the constraint is inside the house — an access point in the wrong place, a bad run of cable, a device stuck on the 2.4 GHz band. If the LAN number is comfortably above, your plan or your provider sets the ceiling and no amount of Wi-Fi tinkering will move it.
This test leaves your local network. It contacts Cloudflare’s public speed-test endpoints, because measuring your internet connection requires sending traffic over your internet connection. The app asks for your consent the first time and will not run it until you agree. Latency under load is measured during this same test, so it travels with it; device discovery and the ping monitor stay on your local network, and scheduled monitoring follows whichever test you point it at.
“Same network” is a heuristic, not recognition. To pair an internet result with a LAN result, PulseLAN checks whether your current local address falls in the same /24 range as the stored one. That is a reasonable proxy for “still at home”, and nothing more — a different network that happens to use the same address range would look identical to us. If there is no recent LAN result to compare against, you get the internet numbers with no verdict rather than a guess.
A device tested against itself is not a LAN result, and we don’t treat it as one. Point the browser test at a PulseLAN server running on the same machine and you will get a spectacular number — thousands of Mbps, a fraction of a millisecond of ping. It is a real measurement of the wrong thing: your operating system short-circuits traffic addressed to the machine’s own address before it ever reaches the network adapter, so what you measured is memory bandwidth and software overhead, not your network. PulseLAN detects this, labels the result plainly wherever it is shown, and keeps it out of the bottleneck comparison entirely — because nothing a real link can do would ever beat it, and one such result would otherwise pin every internet verdict on that network to “your ISP is the limit”. The result is kept in your history rather than discarded; it just says what it is. For a real LAN figure you need a second device.
Latency under load (bufferbloat)
Measured as part of the internet speed test above, not as a separate run. It pings while the link is idle, then keeps pinging while the download saturates it, then again while the upload saturates it. It reports how many milliseconds each of those adds, and grades the result A to F.
This is the measurement that explains why a call falls apart the moment someone starts a big upload. Throughput alone hides it: a link can post a perfectly good Mbps figure and still park your packets in an oversized queue for hundreds of milliseconds whenever it is busy. That queueing delay is bufferbloat, and it is what breaks calls, games, and anything else that cares more about when a packet arrives than how many arrive. An A means latency barely moves when the link is saturated. An F means anything interactive will suffer whenever a transfer is running.
The letter grade is ours, not a standard. It is a plain reading of the added latency we measured, on our own thresholds — useful for comparing before and after a change, not a certification of anything. The raw milliseconds are always shown next to it, and they are the number to trust.
It measures the internet path, at that moment. Because it rides along with the internet speed test, the queueing it finds is anywhere along the path to Cloudflare — most often your own uplink, but not necessarily. Whatever else was using the link at the time is part of what you measured, so run it twice before drawing a conclusion. Measuring latency under load on a purely local transfer is not something PulseLAN does yet.
LAN device discovery
Lists the devices currently visible on your network, each with the best name we can actually obtain — and a label saying where that name came from.
A name is one of three things: an mDNS/Bonjour name the device advertises about itself, a reverse-DNS name your router or DNS server returns for its address, or the PulseLAN device name if PulseLAN is running there. Every entry is tagged with which of those it is, so you know how much to trust it. Where a device offers none of the three, it stays an IP address — we would rather show you a number than a guess. Devices running PulseLAN get a one-tap test to this device action, which drops you straight into a LAN speed test against it.
We do not identify manufacturers or device types. PulseLAN does not look up MAC address prefixes and does not infer what a device is. If an entry reads like a brand name, that is because the device said so itself, not because we decided.
This is not a security scanner and does not detect intruders. It cannot tell you whether a device belongs on your network, and a device that keeps quiet may not appear in the list at all. Treat it as a convenient way to find something to test against, not as an inventory or an alarm.
Ping and packet-loss monitor
A continuous probe against one target with a live chart: minimum, average, and maximum round trip, jitter, and packet loss as a percentage. It exists to separate two problems that feel identical and have completely different fixes — is the connection dropping, or is it just slow?
Steady round trips with a rising average is a congestion or distance problem. Mostly fine round trips punctuated by losses is interference, a failing cable, or a saturated link discarding packets — and no amount of extra bandwidth will fix it. Leave the monitor running while you reproduce the fault, and the chart tells you which one you have.
This is a TCP-connect probe, not ICMP. It opens a TCP connection to a port on the target and times how long the handshake takes; a probe that does not complete in time counts toward the loss figure. Mobile platforms do not hand apps the raw sockets that an ICMP echo — what the terminal’s ping command sends — would require, so this is the honest alternative rather than a shortcut.
Expect the numbers to read a little higher than ping. A TCP handshake is more work than an echo reply, and some devices treat the two kinds of traffic differently. If you compare against a terminal, compare the shape — trend, jitter, loss — rather than expecting the absolute milliseconds to match.
Scheduled monitoring, regression alerts, and CSV export
Re-runs a test on an interval you choose and tells you when the result has genuinely got worse — on a rule deliberately tuned to stay quiet. Point it at a local test and it stays on your network; point it at the internet test and each run reaches Cloudflare, exactly as a manual run would.
An alert fires only after three consecutive results land below 70% of the recent median. One bad sample is not an alert. Somebody starting a large download is not a network fault, and a tool that notifies you about it gets muted inside a week — which is the real failure mode of alerting, and the most common complaint about the tools that do it. PulseLAN would rather miss a marginal decline than train you to ignore it. Three in a row, well below your own recent normal, is a change worth looking at.
History exports to CSV — timestamps and every measured figure, in a file you can open in a spreadsheet. That is the format worth having when you are telling an ISP the problem is repeatable: a dated table of results is considerably harder to wave away than “it feels slow in the evenings”.
There is no 24/7 or background monitoring, and we won’t claim there is. PulseLAN does not install a service or a daemon. What monitoring does while you are not looking at it depends entirely on the platform:
| Platform | What monitoring does |
|---|---|
| iOS | Runs only while the app is open and on screen. Lock the phone or switch to another app and monitoring stops. |
| Android | Continues with the screen off, for as long as the monitoring screen is the one open in the app. |
| Windows & macOS | Runs while the PulseLAN window is open. |
For long-term logging, the arrangement that actually works is a desktop you leave awake with PulseLAN open on the monitoring screen, and a CSV export when you want the record. A phone in your pocket is not watching your link overnight, and we are not going to imply otherwise.
All of this sits around one number
The tools above are context. The measurement PulseLAN is built for is still the one between two of your own devices — download, upload, ping, and jitter across your own Wi-Fi and your own cabling, on a link no internet speed test ever touches.
Every tool on this page lives in the app; this website doesn’t run tests and never sees your results.