# Why Can't I See Packet Loss in Path Visualization?
When a user reports an issue like "choppy audio" or "lag/delay," you might check the [**Network > Overview**](https://docs.thousandeyes.com/product-documentation/internet-and-wan-monitoring/viewing-data/using-the-network-overview) view and see packet loss on the timeline. However, when you switch to the [**Network > Path Visualization**](https://docs.thousandeyes.com/product-documentation/internet-and-wan-monitoring/path-visualization) view to find exactly *where* the loss is happening, the path might look completely clean.
This leads to the common question: *"Why can you not show me the exact place where packet loss shown in the table data is on the path visualization?"*
The short answer is that **Network Overview** and **Path Visualization** use two different methods to collect data.
* **Network Overview (End-to-End):** Sends a continuous stream of packets directly to the target to check overall connection health. It is highly sensitive and quickly detects if the user is experiencing a poor connection.
* **Path Visualization (Hop-by-Hop):** Sends fewer packets specifically to map the route step-by-step. Because it sends fewer packets, it might miss sporadic or short-lived loss events.
This is not a bug; it is two standalone tests that each collect their own data.
The two methods are documented in [Network Tests Explained](https://docs.thousandeyes.com/product-documentation/tests/network-tests/network-tests-explained).
## Troubleshooting Decision Tree
When you see packet loss in the Network Overview but not in Path Visualization, use this flowchart to isolate the fault domain (device vs. network vs. app) and determine your next steps.
```mermaid
flowchart TD
Start([User reports issue
e.g., choppy audio]) --> CheckOverview[Check Network Overview]
CheckOverview --> IsLoss{Is there packet loss?}
IsLoss -- Yes --> CheckPath[Check Path Visualization]
IsLoss -- No --> AppIssue[Likely application issue.
Check app server health or CPU/memory.]
CheckPath --> PathShowsLoss{Does Path Viz
show red nodes?}
PathShowsLoss -- Yes --> IsolateNetwork[Network issue isolated.
Identify the specific provider/hop and escalate.]
PathShowsLoss -- No --> CheckTarget{Is loss only at
the final target?}
CheckTarget -- Yes --> TargetIssue[Target issue.
Check if target is rate-limiting or overwhelmed.]
CheckTarget -- No --> CheckTiming[Check for sporadic loss.
Review multiple test rounds.]
CheckTiming --> IsSporadic{Is loss sporadic?}
IsSporadic -- Yes --> Transient[Transient network issue.
Continue monitoring.]
IsSporadic -- No --> AddAgents[Add more agents or
path traces to increase visibility.]
```
## Common Reasons for Missing Loss in Path Visualization
If the path looks clean but the user is experiencing issues, consider these common reasons:
### Timing and Packet Count Differences
End-to-end measurement (Overview) sends a steady stream of packets, while path discovery sends only a few packets per step. If the network drop is very brief, the continuous stream will catch it, but the path discovery might miss it.
### Packet Loss on the Target (the App Server)
Sometimes the network path is perfectly fine, but the destination server (the application) is dropping traffic. This can happen if:
* The server is overwhelmed and cannot accept new connections.
* The server is rate-limiting incoming traffic to protect itself.
* The server's CPU or memory resources are exhausted.
### Agent Count and Limited Visibility
If the packet loss is occurring in a specific network segment that only one user (or one agent) is traversing, it might be harder for Path Visualization to pinpoint. When multiple users from different locations test the same target, Path Visualization has more data points and can more easily highlight the problematic hop.
## Actionable Remediation Steps
Here is how you can adjust your testing strategy to pinpoint the network issue and help resolve the user's ticket:
### Review Multiple Test Rounds
Do not just look at a single snapshot in time. If a user is experiencing consistent "lag," review multiple rounds of Path Visualization data. Eventually, the path discovery process will likely catch the forwarding loss.
### Increase the Number of Agents
If possible, add more agents to the test. More agents in different locations give a broader perspective and increase the chances of pinpointing where the loss is occurring, especially as paths converge closer to the target.
### Run More Parallel Path Traces
You can increase the sensitivity of Path Visualization. In the test configuration, under the **Advanced Configuration** tab, change the **No. of Path Traces** from the default of 3 up to 10. This makes it much more likely to detect even minor packet loss along the path.
### Check the Return Path (Agent-to-Agent)
Traffic often takes a different route back from the server to the user. If the forward path looks clean, the issue might be on the return path. Setting up an [agent-to-agent test](https://docs.thousandeyes.com/product-documentation/tests/network-tests/agent-to-agent-test-overview) allows you to measure traffic in both directions independently, helping you isolate return path issues.
***
## Technical Reference
For deeper root cause analysis and isolating fault domains, review the underlying measurement mechanics distinguishing transit anomalies from terminal node drops.
### Probing Physics: End-to-End vs. Path Trace
| Component | Probe Volume | Methodology | Expected Target Response |
| -------------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **End-to-End Measurement** | 50 packets per test round | Direct stream to target. Measures arrival timings or acknowledgment responses to calculate loss, latency, and jitter. | Data payload ACKs or ICMP Echo Replies. |
| **Path Discovery** | 3 packets per TTL | Paris Traceroute-based. Probes sent with sequentially increasing TTL. Nodes return ICMP Type 11 (Time Exceeded). | TCP SYN, ACK / RST, ICMP Type 0, or custom UDP (agent-to-agent). |
### Isolating Terminal Loss Signatures
When end-to-end measurements report loss but Path Visualization shows a clean transit path, the target (terminal node) is likely discarding traffic. Compare the test protocol against these common firewall or OS stack behaviors:
| Protocol / Flag | Root Cause | Observable Signature |
| ----------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **TCP SYN** | Target SYN backlog is full. Target ignores new SYN packets. | Intermittent connection failures; established sessions remain healthy. |
| **TCP SACK** | Outdated TCP/IP stack with buggy Selective Acknowledgment (SACK) implementation. | Constant, low-percentage packet loss specifically in SACK-based tests. |
| **ICMP** | Target ICMP rate limit threshold exceeded. | Drops occurring consistently after a specific probe volume. |
| **Rate Limiting (Any)** | Target or upstream firewall actively policing traffic. | Alternates between 0% loss and high loss in a periodic pattern. |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.thousandeyes.com/product-documentation/internet-and-wan-monitoring/path-visualization/troubleshooting/why-cant-i-see-packet-loss-in-path-visualization.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.