When the internet goes down, who is actually responsible?
Three providers, three diagnoses, and a company at a standstill while they argue. This is not bad faith: it is a predictable consequence of splitting the work.
When a fault touches the network, the connection and the applications at once, each provider finds that their own scope is working, and they are usually right. Nobody is lying, but nobody is looking at the whole. The downtime then comes from coordination rather than from the fault itself. That is the hidden cost of splitting work between operator, IT provider and software vendor.
The scenario repeats in almost every company with three separate providers. The phones stop working, the business application will not load, and every desk shows a connection error.
The operator tests the line: it responds, the link is fine. The IT provider checks the servers: they are running. The software vendor confirms the service is available to every other customer. Three accurate answers, and a company still at a standstill.
Why everyone is right
Each provider owns a scope, and checks it properly. The trouble is that real faults almost always sit between two scopes, where nobody has a mandate to look.
- An ageing switch takes down the VLAN carrying telephony: the operator link is fine, the server is fine, and nothing gets through.
- A firewall rule changed for a new tool blocks a flow nobody documented.
- An IP lease renewal shifts a static configuration set three years earlier by someone who has since left.
The real cost is not the fault
On a full day of downtime, the repair itself often takes under an hour. The rest is coordination: reaching the right person, running the diagnosis a third time, waiting for a callback, getting one third party to agree to test at the same moment as another.
That is what costs, and it is the only part the company endures without being able to act. It appears on no invoice, which is why it is rarely measured.
Three ways to cut that time
- Document the joins. An up-to-date diagram of what connects to what (operator link, firewall, switches, VLANs, servers, external services) removes half the back and forth.
- Name someone responsible for coordination, before the incident. This is not a technical role, it is a mandate: somebody whose scope is the whole.
- Test the chain, not the links. A test proving the server responds proves nothing; a test proving a user desk reaches the business application proves something.
A single provider: what it changes, and what it does not
Bringing connectivity, networks, IT and security under one partner removes the negotiation between providers: the diagnosis happens once, across the whole.
It does not remove faults, and that needs saying plainly. Fibre will still be cut, hardware will still age. What changes is the delay between the moment the company calls and the moment somebody actually works on the problem, without first having to prove it is not the neighbour's fault.
The trade-off deserves weighing: you concentrate dependency on one player. It is worth demanding transferable documentation and real visibility over the infrastructure in return, so the company stays in control of its own environment.
Frequently asked questions
- How do I work out which provider is responsible for an outage?
- By testing the full chain rather than each element in isolation: does a user desk reach the final service? If yes at one step and no at the next, the join between those two steps identifies the scope concerned. Without an up-to-date infrastructure diagram, this is very hard to do.
- Should I really consolidate all my providers?
- Not automatically. Consolidation makes sense when faults drag on in coordination rather than repair, and when nobody in the company has time to arbitrate between suppliers. If incidents are rare and handled well, the current split may be perfectly fine.
- What should I ask a provider to avoid this situation?
- An up-to-date, transferable infrastructure diagram, the list of critical flows between components, and a named point of contact for coordination when an incident spans several scopes.
Next step
Published 26 August 2026 · Équipe Skill Group, Conseil & pilotage
Going further
Internet keeps dropping at your company: how to find the real cause
Repeated outages almost always have an identifiable cause. Here is the method to find it, and why a second router usually fixes nothing.
FTTH or FTTO: which fibre should your business choose?
Both are called fibre, yet they offer very different services. The real deciding factor is not speed, it is what happens when the line goes down.
Ambulances and approved medical taxis: stop losing jobs over the phone
In medical transport, a missed call is a lost job, and often a client who will call a competitor next time. Here is what can actually be fixed.