‘The internet is down’: how to narrow down the problem before calling anyone

‘The internet is down’ can mean many things

In a school, where one issue can leave a whole class waiting, the initial goal should not be to find out the exact cause immediately. The first thing is to narrow down where the problem is. Knowing whether it affects one person, one classroom, one floor or the whole school lets whoever is going to deal with the issue start work much sooner and avoids making unnecessary changes to a network that may well be working properly.

From the classroom, many different faults look exactly the same. The teacher opens a page and it does not load. For them, the internet is not working. But technically it could be that the laptop has not received a network connection, that the Wi-Fi has a problem, that the school has no internet access or simply that the platform they are trying to use is temporarily out of service.

That is why one of the most common mistakes is to start by restarting equipment before knowing what is happening. Restarting the router, a switch or an access point may even make the problem go away, but that does not mean we have found out what the cause was: if it works, nothing has been learnt and the fault will come back; if it does not, the evidence has been destroyed and there are two issues instead of one.

Before touching anything, it is worth spending three or four minutes asking a few questions. Often they will not yet tell you which component is failing, but they will greatly reduce the number of possibilities. By the end you may not know what has failed, but you will know where there is no need to look.

The first question: who is it happening to?

This is probably the check that gives the most information and, at the same time, one of those least often included in the initial report. When someone says ‘the internet isn't working’, they are usually talking just about what they are seeing on their own device. Scope is not assumed: it is checked. Asking whether it works for the person sitting next to them, whether the next classroom has a connection or whether the school office is working normally takes thirty seconds that save half an hour, and it has to be done before going up to any cabinet.

If just one laptop is failing and the rest of the class is working normally, there is little point in starting by checking the school's main connection. The problem will probably lie with that device, its configuration, its user or its access to the network. If, by contrast, every device in a classroom is having trouble while the class next door is working normally, the investigation changes and we can focus on the equipment serving that area.

If a whole floor is down, attention can turn to the comms cabinet or the link connecting it to the rest of the network. And if no user in the school has a connection, then it does make sense to check the main internet connection, the firewall or the provider's line.

There is another important scenario: the problem affecting every user of the same application, whatever classroom they are in. In that case the network may be working perfectly and it is the service itself that has the issue.

The second question: what exactly is not working?

‘Nothing's working’ and ‘I can't get into the learning platform’ usually end up being described in the same way, even though the diagnosis is completely different. That is why you should always ask for a specific example: what the person was trying to do, and what appears on screen when they try.

If the user can browse other pages but cannot access a particular platform, the internet connection exists. At that point you need to check whether the problem lies in the service itself, in the user's authentication or in something related to that application. And the check is immediate: log in to that same platform from a connection that does not go through the school network, for example a phone's mobile data. If that does not work either, the issue is outside the building. Most educational platforms also publish a status page where they announce outages, and having it to hand saves a lot of false starts.

The opposite can also happen: servers, printers or other internal resources are still working, but no device manages to reach the internet. That gives a completely different clue, because it shows that a large part of the internal infrastructure is still operational and that the problem is probably closer to where the school connects to the internet.

The third question: is it the Wi-Fi, or is the wired connection failing too?

Another simple check splits the installation in half and is answered without any tools. If, in the same area, a computer connected by cable browses normally and the Wi-Fi devices do not, everything from the internet connection to that cabinet is working, and the problem is confined to the wireless network or its authentication system. If it fails by cable too, you have to go up a level.

You also need to tell the difference between having poor coverage and being connected without internet. They are two situations that can look the same from the outside, but they have different causes. A device that can barely see the Wi-Fi network may have a coverage problem or a problem with the access point that should be serving that area. By contrast, a device that shows an excellent signal and connects correctly but cannot browse is pointing to a different kind of problem, and adding more coverage would not solve anything. That is why it pays to ask what appears in the list of networks, and not just whether ‘the Wi-Fi is working’.

The school's different networks also help to narrow things down. If the teachers' Wi-Fi works and the pupils' does not, the problem is unlikely to be radio coverage. Both reach users through the same physical infrastructure, and you will have to look at the differences between their configuration, authentication or policies.

The fourth question: since when, and what changed

The next question is how long it has been happening. A network that worked yesterday and stopped working this morning presents a different scenario from a device that has never managed to connect properly: the first points to a recent change, the second to a set-up that was never completed.

Behind many issues there is some recent change, even if nobody connects the two. A device may have been updated overnight, or there may have been building work in part of the school, a power cut or a certificate that expired on a date nobody had noted down. Even something apparently low-tech can affect the service: a cabinet left without ventilation, a device unplugged to free up the socket or a cable moved during some works.

Simply asking ‘has anything changed?’ almost always gets a no, because the person answering thinks only of IT changes. It is usually more useful to ask what has been done recently in that area, and to ask the right people: maintenance, the cleaning staff, the contractor that did the building work or the colleague who set up the laptop trolley.

This question becomes especially important at the start of the school year. Over the summer, building works, classroom moves, new equipment, staff changes and configurations nobody has yet used with the school full may have built up. That is why September tends to bring a cluster of issues that actually began weeks earlier.

Once it is narrowed down, the checks should follow an order

Once we know who is affected and what is failing, it makes sense to start carrying out technical checks. The rule is to work from the inside out and from the device where the problem is happening: the one in the office is on another part of the network and will give an answer that is no use. The order matters more than the tools, and jumping to the last step is what leads to the provider being called out over a loose patch lead.

Neither the school's leadership nor a teacher needs to know how to carry out these tests. This part normally falls to the IT lead or the support service. What matters is understanding that there is a logical order, and that the more information the school has gathered before logging the issue, the less time the technician will have to spend working out from scratch what is going on.

• Has the device received a network address? If it has none, or has one of those the system assigns itself when nobody responds, it is not talking to the network: check the cable, the port or the service that hands out addresses.
• Does it reach devices inside the school? If it has an address but reaches nothing on the local network, it is connected but isolated, which points to the port or the segment it has ended up on.
• Does it resolve names? If it gets through by numerical address but not by name, the problem is the name service: the classic cause of ‘the internet is really slow’ that is actually ‘it takes a while to start and then it's fine’.
• Does it get out? If it resolves names and still does not get outside, look at the way out: the filtering, the proxy if there is one, or the link itself.
• Is the provider's link up? Its indicator lights, its status portal and, if there is monitoring, the history for the last hour. It takes a minute to confirm.

You also need to know when to stop investigating

When a lesson has ground to a halt, time counts. The IT lead could keep trying possibilities for an hour and eventually find the cause, but by then the whole lesson may have been lost. That is why the time limit has to be set before starting: once half an hour has gone, it is too late to set it.

During school hours, around ten or fifteen minutes is a reasonable guide for trying to narrow down an issue before escalating it. If after that time it is still not clear what is going on and there are pupils waiting, five more minutes will not make it clear either, and it usually makes more sense to ask for help than to keep testing.

There are also certain situations in which it is better to escalate sooner: if the problem affects the whole school, if there are signs of a hardware or power failure, if the provider confirms an issue in the area or if the affected service is managed by an external provider.

While the diagnosis is under way, the priority during school hours is still for teaching to carry on. Sometimes that will mean finding a temporary solution and looking into the cause afterwards more calmly, once the school is empty. But it comes at a price: restoring the service means the evidence is lost, so the right order is to take notes first and touch things afterwards.

Five pieces of information can save a great deal of time

There is no need to prepare a report every time something fails. A note written during the fault is worth far more than a memory of it later, and all it needs is the time, the place and what was tried.

• The time it started and the time it came back, even if approximate.
• Who is reporting it, from which space and on which device, school-owned or personal.
• Confirmed scope: who else it is happening to and who it is not.
• What was tried and with what result, including anything that made no difference, which also rules things out.
• What was restarted or touched, and at what time.

Notes pay off most with intermittent faults

Saying ‘the Wi-Fi sometimes plays up in the morning’ adds very little, and it is precisely those faults that wear people down. By contrast, having several issues logged with the time, classroom and users affected makes it possible to start finding patterns: it may always coincide with one area, with a particular group, with a specific time or with the moment some piece of equipment is switched on.

It also makes it much easier to take up an issue with a broadband provider or an external supplier. Being able to say that the service went down at 10.12am, came back at 10.27am and affected the whole building gives far more information than simply reporting that ‘the internet was bad this morning’.

Over time, this same habit makes it possible to build something even more valuable: knowledge of the school's own infrastructure. Knowing which cabinet serves each area, having the data points labelled, knowing which access point covers each classroom or whom to call for each platform greatly reduces the time needed to deal with the next issue.

The best issue is the one detected before it reaches the classroom

Narrowing down a report properly helps a great deal when there is already a problem. But a well-managed network should make it possible to detect some of those issues before a teacher has to report them.

If an access point stops responding in the early hours, a link between cabinets goes down or a critical device shows problems, monitoring can raise an alert before lessons start. That allows the team to step in more calmly and, in many cases, to deal with the situation before it has any impact on pupils and teachers.

At PenwinEdu we monitor the networks we manage 24/7 and deal with issues with a response time of under four working hours. But the advantage of working with schools for years goes beyond receiving an alarm. We know the difference between an issue that affects an office and one that brings a classroom to a halt; we know that certain jobs can wait until the afternoon while others need sorting out during the lesson, and we understand that the purpose of technology is to keep the school running.

Sorting things out quickly starts with understanding what is failing

When someone says ‘the internet is down’, the solution should not start with restarting equipment at random. It starts with finding out who is affected, which service is failing, whether it happens over cable and Wi-Fi and how long it has been going on. Four simple questions can narrow the problem down a great deal and let the IT lead or the support service get to the cause sooner.