Is It Actually the Network? How to Isolate the Likely Cause of User Complaints

“It’s slow” is not enough information

Consider a user who reports that an application is slow. The application team doesn’t report any issues on their side as the infrastructure shows no outages or degradation. A similar response comes from the network team. All routers and switches are reporting normal values and there are no reported outages from the service providers. 

When the NOC dashboard is green, the ticket begins moving between teams because each team can show that its own systems appear healthy. Nobody can show what the user experienced. 

When the root cause is not identified, a ticket is everyone’s problem. In this situation, the goal should not be to deflect the ticket but to identify the most likely fault domain using evidence.

Why healthy infrastructure does not settle the question

The fundamental problem when handling user tickets is that infrastructure health doesn’t provide the full picture. When analyzing end-user experience, beyond the status of the network and application, IT teams must also consider external networks and application dependencies (e.g. SaaS or cloud). 

When remote users complain about application performance, there are several factors that should be considered, such as:

• The user’s device, such as CPU performance and memory consumption
• The local network where the user sits, including the Wi-Fi connection
• The ISP and the internet path
• The DNS
• The corporate network, including the VPN/SASE connection
• The application or its dependencies

Any of these domains can produce the same symptom: ‘The application is slow.’ To narrow the likely fault domain, IT teams need a structured network troubleshooting process based on scope, timing, and user-perspective evidence.

Scope, timing, and fault domain

When troubleshooting user issues, start with three questions about who is affected (scope), when it happened (timing), and where the data leads to (fault domain).

Scope: Who is affected?

First of all, we need to understand whether one or more users are experiencing the same problem. If multiple users are involved, then we need to identify the common thread. Are they using the same ISP, Wi-Fi network, VPN gateway, or application? Comparisons with unaffected users, locations or services make these conclusions stronger. That information will give us a starting point to identify the root cause.

Timing: When did it happen?

It’s fundamental to know the timeline of a problem. Whether it’s happening now, or occurred in the past, accurate timing information and historical data help narrow the focus of the troubleshooting process. With a specific time window we can analyze changes that could explain the origin of the performance issue.

Fault domain: Where does the evidence point?

Once the team understands the scope and timing, it can identify the fault domain that could be responsible for the complaint. Generally, no single measurement provides that answer. A failed application test confirms the user experienced a problem, but it does not explain whether the cause was Wi-Fi, the ISP, DNS,  or the VPN for instance. The evidence becomes more useful when multiple measurements are compared over the same period. These measurements give the IT team a defensible starting point: where the evidence points, what it rules out and who should investigate next.

Compare evidence across the user-to-application path

One of the most important phases of the troubleshooting process is comparing performance metrics, tests, and measurements across the user-to-application path. For example, a weak Wi-Fi signal combined with packet loss to the local gateway points toward the user’s wireless connection. If the local network remains healthy but latency or packet loss begins farther along the path, the ISP or internet route becomes more likely. If public services perform normally while VPN access and internal applications degrade, the investigation should shift toward the VPN or corporate network. Similarly, an increase in DNS response time while other connectivity measurements remain stable may indicate a resolver problem. If network, path and DNS measurements remain healthy but application response time rises, the application or one of its dependencies deserves closer attention.

The following table summarizes the most common causes of performance degradation. These signals identify a likely fault domain but they do not always establish a definitive root cause.

An example: A remote user reports a slow application

Let’s apply what was discussed so far. In the following scenario we take the example of a remote user reporting that an application is slow and disconnects from time to time. The user submits a support request indicating the application and timing of the complaint. The application team reports no issues, and the infrastructure supporting the service shows no outages or degradation. No other users are reporting problems with the application, so the team doesn’t believe it’s an application issue. 

The support team then focuses on the first portion of the user-to-application path. They find that the user is connected via Ethernet, ruling the wireless connection out of the equation. The team inspects the historical ping and path analysis measurements around the reported timing. These measurements show increased packet loss starting from the first ISP hop. Network speed tests are also inspected to identify a possible ISP performance issue. The evidence from path analysis (an enhanced traceroute test) points to the user’s local ISP path, not the application or corporate VPN. The remote user, working from home, is given the evidence needed to open a support ticket with their internet service provider

The conclusion would change if other users are reporting application slowness and if the network and DNS measurements remained healthy while HTTP response time increased. Likewise if several users behind the same VPN gateway degraded simultaneously. Another common scenario is remote users connected over Wi-Fi reporting high latency and packet loss on all tests starting from the first hop, which leads to a wireless connection issue.

A practical isolation workflow

The following process turns a vague user complaint into an evidence-based escalation.

Step 1: Confirm the user-visible symptom. Translate “slow” into something measurable, such as increased application response time, failed connections, VPN disconnects, DNS delays, packet loss, or high latency and jitter.

Step 2: Establish the scope. Determine who is affected and compare them with unaffected users, locations, services, ISPs, Wi-Fi networks, or VPN gateways.

Step 3: Reconstruct the relevant time window. Review measurements from before, during, and after the complaint. Record the exact time and time zone, and look for recurring patterns or recent changes.

Step 4: Compare layers and paths. Examine the device, Wi-Fi or local network, internet path, DNS, VPN, and application measurements. Identify which measurements degraded together and which remained healthy.

Step 5: Identify the likely fault domain. State what the evidence supports, what it makes less likely, and what remains unknown. Avoid claiming a definitive root cause unless the evidence proves one.

Step 6: Escalate with an evidence package. Include the symptom, affected scope, timestamps, relevant measurements, path information, and comparisons with healthy users or services. The receiving team should be able to continue the investigation without starting over.

What a useful ticket escalation should contain

When working on a support ticket, it’s important to define and follow a checklist that includes elements that must, or should be, included in the ticket. The goal of the support ticket is to provide the information required to address the issue and close the ticket.

Here’s a non-exhaustive list of support ticket fields:

• Exact time and duration of the issue: If it’s in the past, provide start and end dates, specifying if it’s recurring. If it’s in the present, provide the start time of the issue.
• What is the user impacting problem: It could be the note sent by the end-user, or a description of a user visible problem.
• Extent of the problem: How many users are involved in the problem, and if they are grouped by a specific common element (region, connection, etc.).
• Data: Any relevant information that is collected about the endpoint, Wi-Fi network, network tests, and so on.
• Any correlated changes: Events like configuration changes, or failure of other systems apply here.
• Likely fault domain and supporting evidence: Any evidence that indicates a possible fault domain, ruling other domains out, should be included in the ticket.

A good escalation does not merely say, “The network is slow.” It gives the receiving team enough evidence to continue the investigation without starting over.

Conclusion

Not every user complaint is caused by the network, but a green infrastructure dashboard does not prove that the network is uninvolved. Measurements collected from the user’s perspective help IT teams establish the scope of a problem, reconstruct when it occurred, and isolate the most likely fault domain. This shortens investigations and reduces unsupported handoffs between teams.

NetBeez uses endpoint and network agents positioned from the user’s perspective to collect this evidence continuously, helping service desk and network teams investigate the conditions users actually experienced.

The same evidence is valuable even when nobody has opened a ticket. In the next article, we’ll examine what network teams should monitor between incidents.

What does your team review when a user reports that “the network is slow”? Follow the NetBeez series as we examine how user-perspective evidence can become part of continuous network operations.