User and endpoint
Is the client healthy, connected and making the expected request?
Troubleshooting Approach
99 problems, but a switch ain’t one.
My troubleshooting rule is simple: be the packet. Trace the service journey from the user to the outcome, stop at every hand-off, and ask one question: has it passed this gate?
The Starting Point
Start with the journey, not the loudest theory.
A reported “network issue” can originate anywhere: the user device, name resolution, identity, a firewall rule, a proxy, an application, a dependency or the return path. Starting with a preferred answer slows everyone down.
Instead, I model the real path taken by the request and response. Each component is a gate. Evidence that a packet or request has crossed one gate narrows the search and gives the next investigation a useful starting point.
Be the Packet
At every gate: has it passed this point?
The exact path changes with the service, but the method stays the same: establish the expected journey, test it, record what is known, and move only when the previous gate is evidenced.
→
Access and network
Has DNS resolved correctly? Has traffic reached the expected route, switch, gateway and firewall?
→
Security and edge
Has identity, policy, proxying, inspection or rate limiting allowed the request through?
→
Application and dependency
Did the service receive the request, process it and obtain what it needs to respond?
→
Return path and experience
Did the response return successfully, in time, and with the result the user expected?
“The switch ain’t one” is a reminder not to blame the network by default. A switch can absolutely be the fault; it simply earns that conclusion through evidence, like every other component.
Evidence at the Gate
Make the next question smaller.
Define the expected path
Agree what “working” should look like: source, destination, protocol, identity and expected response.
Test the hand-off
Use the smallest useful observation: logs, metrics, packet capture, traces, configuration or a controlled request.
Record what it proves
“The request reached this point” is more useful than “we checked the firewall”. It prevents repeated work.
Choose the next owner
Pass a bounded question to the subject-matter expert responsible for the next gate, with the evidence attached.
Collaboration and Ownership
Stop moaning. Start owning.
Many voices. Clear accountability.
Effective troubleshooting is cross-team by design. Network, security, platform, application, service desk and supplier teams may all have part of the answer. Bringing them together early improves the quality and speed of the investigation.
Collaboration should not mean diluted responsibility. “Stop moaning. Start owning.” means each gate has a subject-matter expert who owns the evidence, the decision and any corrective action within their domain. The incident lead keeps the end-to-end journey visible, connects the teams and makes sure no hand-off becomes a black hole.
That balance avoids both extremes: isolated technical silos and large calls where everyone is present but nobody is accountable. It also avoids the blame thrower: the habit of passing an issue to another team without evidence or a clear question. Good escalation carries the facts, the tested gate and a named owner for the next action.
The Outcome
Faster diagnosis, stronger learning and fewer repeat incidents.
Working the path methodically makes troubleshooting calmer and more transparent. It gives stakeholders a clear account of what is known, what is being tested and who owns the next action. More importantly, it turns an incident into practical knowledge that can improve monitoring, runbooks, design and future delivery.