"It's not my system" isn't good enough — a 3am story

I got woken up in the middle of the night by an on-call technician. That sentence alone tells you something about this job — but the real lesson isn't "IT is stressful." It's about what troubleshooting actually means.

The ticket

A weather forecast service the client used was inaccessible. On the surface, almost trivial. Except this client ran large national infrastructure construction projects, and that service fed directly into the decision of whether to keep a site open that day — whether conditions were safe enough for people and heavy equipment. Service down, forecast invisible, and the decision defaults to the safe option: shut down. Real money, real schedules, real safety, all resting on whether a website loaded.

The dead end that wasn't

The site worked fine from my connection. It worked fine from the on-call tech's connection too. Both of us, independently, saw a working service. The client, on their own network, could not reach it at all.

That's the moment a lot of people say "it's not my system, it's working on my end," and close the ticket. Technically true. Completely useless to a client who can't make a safety decision.

"It's not my system" is a true statement and a useless one at the same time. Your job, as the entire IT department for a client, isn't to prove the fault isn't yours — it's to find out what's actually broken, regardless of whose infrastructure it lives on, because the client has no one else to call.

Following the path, not the excuse

If a service works from two outside connections but not from the client's own network, the problem sits somewhere in the path between them — not the service, not the local machine, the road in between. That's routing. So we traced the network path from the client's location out, hop by hop, looking for where it broke compared to a working path.

We found it: the client's ISP was routing traffic to that service through a secondary, backup route — and that route had failed equipment sitting in it, waiting on spare parts. The main route was fine. We didn't fix a server or a firewall. We identified, from outside, a dead piece of equipment on the client's ISP's alternate route — and told the client exactly what to say when they called, which is usually the fastest path to a fix.

What to actually take from this

"Not your system" is the start of the investigation, not the end. Don't stop there.

Use elimination methodically. We knew it wasn't the service — it worked from elsewhere. We knew it wasn't the client's machine — that would look different. That left the path between, and that's where we looked.

Document the path to a fix, not just the fix. Six months later, at 3am, tired, you won't remember your own reasoning unless you wrote it down.

The process is the safety net — not a team. When you're the only IT person a client has, there's no colleague to catch what you missed.

The call ended around 4am. The client got exactly what they needed to call their ISP with the right information. And I went back to bed reminded, again, that the hardest part of this job usually isn't technical difficulty — it's not giving up at the first honest-sounding excuse to stop looking.

Next: the uncomfortable tension between working hard enough to actually be good at this, and this job slowly consuming your life if you let it.