Acutis logo Acutis Go network & machine diagnostics

Network or machine, across 600 computers

The short answer: the manual method works. Compare two devices, split the path, ping the gateway then the internet — that settles one laptop in about a minute, and it is still the right thing to do.

It breaks at scale for a reason that has nothing to do with the technique: it only runs when someone complains, on one machine, after the fact. A fleet's real problem is not diagnosing the ticket in front of you. It is the tickets that never get filed, the ones you can't reproduce because the moment has passed, and the ones you can't tell apart because each was investigated alone.

The four places the manual method quietly fails

1. It's reactive, so you only see what gets reported

Most people do not file a ticket when the connection is bad for ten minutes. They reload, wait, blame the internet, and get on with their day. So the events you investigate are a biased sample: the ones bad enough or long enough to be worth a complaint. If a site has been degraded every afternoon for three weeks, the ticket queue may contain nothing about it at all.

2. The evidence is gone by the time you look

Someone reports that things were slow an hour ago. You run the tests now and everything is fine. There is no honest verdict to give — not because you lack skill, but because the fault is not happening while you are measuring. Intermittent problems are the majority of real network complaints and the manual method is structurally blind to them.

3. One machine can't tell you which side is at fault

This is the important one. On a single laptop, "compare against another device" is the whole trick — and at your desk you have a phone to compare against. Across a fleet you have the same question with no comparison available: a user in one office says the VPN is slow, and you have no idea whether the other forty machines at that site agree. The signal that decides network-versus-machine is the pattern across many machines at once, and that is exactly the thing one-at-a-time triage cannot see.

4. Nothing accumulates

Every investigation starts from nothing and ends when the ticket closes. Ask "is this getting worse?" or "did the change last month help?" or "which site is actually our problem?" and there is no record to answer from. Ninety separate one-off diagnoses do not add up to knowing anything about the fleet.

What it costs, concretely

SituationOne machineA fleet
Something is slowRun two tests, compare, doneNo idea if it's one user or a whole site
Problem is intermittentWait and retestEvidence gone; ticket closed "could not reproduce"
User blames the networkProve it in a minuteTech dispatched to a machine fault
Network really is at faultCall the ISPWeeks of individual tickets before the pattern is spotted
"Is it getting worse?"You rememberUnanswerable — nothing was recorded

The expensive failure is the third row. A machine fault reported as a network fault sends someone to the wrong place, and a network fault dismissed as "that user's laptop again" sits unfixed while more tickets pile up behind it. Both are misattribution, and misattribution — not diagnosis time — is where the real cost sits.

What actually changes at scale

The fix is not a better test. The tests are fine. What changes is when and how many:

Continuous instead of on-complaint
The checks run all the time, so the intermittent afternoon problem is recorded while it is happening rather than reconstructed afterwards from memory.
Many machines instead of one
Ten machines at one site degrading together is a network fault, stated as a fact rather than a hunch. One machine degrading while its neighbours are fine is a machine fault. That comparison is free once every machine reports.
History instead of a moment
"This site has been bad every weekday afternoon for three weeks" is a sentence you can take to an ISP or a vendor. A single screenshot is not.

None of that requires touching the network. It requires the endpoints to answer the same question they always answered — is it the network or the machine? — continuously, and in one place.

That is what Acutis Go does

A free 7 MB observe-only agent on Windows, macOS and Linux runs the same checks every 60 seconds and reports a plain verdict — network or machine — for every machine, with the history behind it. It is observe-only by design: it changes nothing, opens no inbound port, and cannot push configuration, so the security review is short. Start with one machine free.

Get the agent

Frequently asked questions

Why isn't ping enough for a fleet?
Ping is a fine instrument and nothing here replaces it. The limitation is that it answers about one host at one moment, when a human runs it. Fleet questions are comparative and historical — is this site worse than that one, is it worse than last week, are these fifteen tickets one problem or fifteen — and no single-shot command answers those.
Can't our RMM already tell us this?
RMM tools are built to patch, inventory and remote-control machines, and they report whether an agent is reachable. That is a different question from whether the path between a machine and the things it uses is degraded, and on which side the fault sits. Reachable-but-degraded is the state most user complaints live in, and it usually reads as green in an RMM.
How do you tell a network fault from a machine fault across many machines?
By correlation. If several machines on the same site or segment degrade at the same time, the shared thing between them — the network — is the likely cause. If one machine degrades while its neighbours stay healthy, the fault is local to it: adapter, driver, CPU contention, VPN, or DNS configuration. One machine on its own cannot make that comparison; a fleet reporting continuously makes it automatic.
Does this need access to our switches, firewalls or routers?
No. This is endpoint-side only. The agent observes from the machine outward and reports what it sees. It holds no device credentials and makes no configuration changes, which is why it can usually be approved as a monitoring tool rather than a network-management deployment.
What do I do with the answer once I have it?
Two things you could not do before. Route correctly the first time — machine faults to desktop support, network faults to whoever owns that link — instead of discovering the routing was wrong a day later. And escalate with evidence: a record of degradation with timestamps across multiple machines is what makes an ISP or a vendor act, where a single user's complaint does not.