Maintenance
Part of Business internet: 4 differences from home service and 7 questions to ask
What does a speed test actually hide about business internet?
Business internet measurement without buying anything: what a speed test hides, how to log delay and loss over days, and how to turn the log into a fault report.
No tool you buy can make a bad connection good. You can measure a short list of things for free.
They show whether the connection is the problem at all and turn "the internet is rubbish today" into a fault report a provider must act on.
This page is about that measurement, and about why the test almost everyone reaches for first is the wrong one. The buying side of the same question sits in business internet.
What to take away
- No product makes a bad connection good. A week of continuous measurement, costing nothing, tells you whether the connection is even the problem.
- A speed test measures bulk capacity for a few seconds. Calls depend on delay, variation in delay and loss, and none of those appear in that figure.
- Take your target numbers from the platform you actually use, and keep a healthy-week baseline so a later decline is arguable.
What a speed test tells you, and what it hides
A browser speed test pulls a large blob of data as fast as it can and reports a
Speed test vs call quality
Speed test
- Measures
- Bulk capacity
- Duration
- Seconds
- Timing
- One moment
- Shows
- A number
Live call
- Measures
- Delay and loss
- Duration
- Hours
- Timing
- All day
- Shows
- Wobble and gaps
It does not tell you round-trip delay, how much that delay wobbled, or whether anything was lost on the way. Those properties a live call depends on.
So a connection can report an impressive figure while its calls are unusable, and the test never shows why. What a call will not tolerate is set out in voip systems.
It also runs for seconds. Your working day is hours. A test that passes at 09:40 says nothing about the congestion that arrives every afternoon, and afternoon congestion is the most common shape of the complaint.
Measure over time, not once
The useful measurement is boring and continuous: a small, steady stream of
Continuous measurement setup
- Run continuous ping to fixed target
- Record output to a file
- Use wired machine, not Wi-Fi
- Run across full working week
- Include busy hours and one evening
- Run route trace when bad and fine
probes, running for days, logged with timestamps.
Leave a continuous ping running to a fixed, reliable target and record the output to a file. Do it from a machine on the wired network, not over Wi-Fi, so you are testing the connection rather than the office radio. Let it run across a full working week, including the busy hours and one evening.
What you are looking for is not the average. Averages hide exactly the events that ruin calls. Look for the shape:
Measure over time
- Round-trip times that are stable all morning and start climbing after lunch.
- Occasional replies that take many times longer than the typical one, that spread is the jitter your calls are suffering.
- Missing replies, and whether they come singly or in bursts. Bursts are worse; a run of consecutive losses is an audible gap in a sentence.
- Whether the pattern repeats at the same time each day. A daily rhythm points at congestion. Randomness scattered through the day points at something faulty.
That log is where business internet troubleshooting starts, so keep it. Also run a route trace when things are bad and again when they are fine, and keep both. Comparing the two shows whether the delay appears on the first hop inside your building, at the edge of your provider's network, or somewhere well beyond either.
Where the fault usually is
Work outward, because the odds run in that order.
Work outward to find fault
- Start at the desk
- Test second machine on same cable
- Check office network and Wi-Fi
- Repeat test on wired connection
- Measure the connection itself
- Check the far end
Start at the desk: one misbehaving machine is not a connection problem.
Test a second machine on the same cable before going further.
Then the office network. Wi-Fi accounts for a large share of complaints reported as internet faults. A device at the far end of the building, competing with every other device and every neighboring network, will produce exactly the symptoms of a bad line. Repeat your test on a wired connection; if the problem disappears, you have a radio problem, not a circuit problem, and no amount of arguing with your provider will fix it.
Then the connection itself, measured as above. Where the line is a radio path in the first place, fixed wireless adds a second set of causes to rule out.
Then the far end. If calls to one destination are bad and everything else is fine, the fault may be at the other end or in the platform, not in your building.
Get your target numbers from the right place
Do not adopt thresholds for latency, jitter or loss from a general article, including this one. The regulator's broadband speed guide is a reasonable way to translate activities into a requirement, and its continuous Measuring Broadband America program exists because one test at one moment is not a measurement.
The platform you use for calls and meetings publishes its own network requirements. Take the numbers from that documentation: they are what the software was designed against. Hold your connection to them.
If you are being sold a connection for voice, ask the provider what it commits to on those same three properties. Note whether the answer is a commitment or a hope.
Turning a log into a fault that gets fixed
Providers close vague tickets. They act on specific ones. When you report a
problem, give them:
What to give your provider
- Exact times the problem occurred
- Measurement log covering good and bad
- Confirmation tested wired, multiple devices
- What changed and when
- Ask for fault reference
- Ask for next update time
Ask for the fault reference and the next update time. If your agreement has a target restoration time, note when the clock started, because it usually starts when you reported it through the right channel, not when the problem began.
Two things worth setting up before you need them
Keep a baseline. Run the same measurement for a week when everything is working
Set up before you need them
- Keep a healthy-week baseline
- Archive it before problems start
- Watch upload side too
- Check for backup jobs overrunning
Watch the upload side too. Most monitoring habits watch download because that is what the tools default to. If your business hosts calls or pushes backups offsite, the upload direction is the one that saturates first, and a backup job that has quietly started overrunning into the working day is a common, completely invisible cause of bad calls.
The short version
Measure continuously, from a wired machine, over days. Look for shape rather than averages. Rule out the desk and the Wi-Fi before blaming the line. Take your target numbers from the platform you actually use. Keep a healthy-week baseline so you can prove a change.
Installation and handover are a different job from measurement, and setup and troubleshooting covers that stage.
Common questions
How long should we measure before reporting a fault?
Long enough to show the pattern, usually several days including the hours people complain about. A single bad afternoon is easy to dismiss.
Does the measuring machine need to be anything special?
No. Any always-on computer on a wired connection will do. What matters is that it stays in one place and keeps a timestamped log.
Our provider says the line tests fine. Now what?
Ask them what they tested and when. A line test at midnight proves the circuit is up, not that it was usable at four in the afternoon. Send your log with times.
Should we buy a monitoring product?
Only after the free version has stopped being enough. A logged ping and a route trace answer most small-office questions.
