I apologise for the second IT Crowd reference in as many posts, but there’s a reason this phrase is a cliché. Here’s why I believe it’s not the best first step for technicians and why users rebooting can be less helpful than they think.

While a reboot often seems to fix the issue, it frequently addresses the symptom, not the root cause. The user might get the satisfaction of a quick fix for a meeting or presentation, but the problem likely goes unrecorded and uninvestigated. This means the issue resurfaces when the root cause is triggered again, leaving someone else to face the same “solution” of rebooting without raising a ticket.

I’ve seen this play out in a business setting where the concierge had a SIM removal tool readily available – it was the default response. Here’s the problem: rebooting often clears temporary files, including any relevant logs (if present) that wouldn’t be committed to permanent logs. Additionally, there are often other tests I, as a technician, might want to perform before a reboot.

This isn’t to say I never reboot devices. However, it’s rarely the first course of action. Only in time-sensitive situations where it’s the fastest resolution would I consider it. Thankfully, there are tools and methods to retrieve and check logs, and multiple ways to connect to devices for these tasks. Often, “black box” systems house different systems or modules that can be checked via proprietary tools or even the trusty command line. These tools can reveal which part of the device failed, and with some knowledge (either mine or through the support line I have access to), we can sometimes determine how it failed and work towards a resolution.

In the case I mentioned earlier, I was able to identify a device in a “frozen” state, perform checks, and retrieve all logs. Working with the supplier’s support team, we not only found the cause of the issue but confirmed they’d already addressed it with a firmware update (firmware updates aren’t always a magic bullet). This meant further collaboration with the client, as they had strict firmware version control and change management processes. However, the issue was resolved, and the SIM removal “reboot switch” became a monument to the problem overcome.

But as I mentioned, sometimes a reboot does fix the issue. How do I confirm the root cause is addressed? Firstly, I’d try to take logs before and after the reboot (where possible), investigate them myself or pass them on to a support team. I’d then update the user on the steps taken but also inform them that if the issue recurs, they should let me/us know again as there’s likely a deeper problem. Additionally, I’d check with suppliers to see if they’ve encountered the issue before and explore further diagnostic options.

What if a user “fixed” the issue with a reboot? First, I’d ask if they know what triggered the problem – perhaps a sequence of actions. I’d then try to recreate the fault. Finally, in both scenarios, I’d ask that if the issue reoccurs, they could try to avoid rebooting before I arrive (understanding this might not be possible). And, if they do reboot, reminding them to update the AV team allows us to at least pinpoint when it happened, aiding further investigation.

Ellery Hulme (they/he)

Ellery Hulme Meme: Don't Turn AV On and Off | Read the Blog Post for the Fix

Have You Turned It Off and On Again?