ADAM PULSE How to prove your ISP is causing packet loss, latency or internet outages
Your users report that the internet keeps dropping.
Your firewall looks healthy.
Your internal network appears stable.
You call the Internet Service Provider.
Their response:
"The circuit is up and we don't see a problem."
Now what?
Intermittent ISP problems can be extremely difficult to escalate because the carrier may begin testing after the condition has disappeared.
The goal should not be to argue that the ISP is responsible.
The goal should be to collect enough objective evidence to identify where network degradation begins and give the carrier a specific incident to investigate.
That evidence can include:
- Exact timestamps
- Local gateway availability
- Firewall availability
- Carrier gateway availability
- External connectivity
- Packet loss
- Latency
- Jitter
- Route information
- Circuit history
- Repeated incidents
- SLA performance
This guide explains how to build a stronger technical case when you suspect an ISP circuit or upstream network is causing business connectivity problems.
How Do You Know if Your ISP Is Causing a Network Problem?
Do not begin by assuming the carrier is responsible.
Begin by isolating the network.
Think of the path as:
User → LAN → Gateway → Firewall → Carrier Handoff → ISP Network → Internet Destination
Then determine where healthy behavior becomes unhealthy behavior.
If internal infrastructure remains consistently healthy while degradation repeatedly begins beyond the customer network boundary, the provider path deserves closer investigation.
What Evidence Should You Collect Before Calling the ISP?
At minimum, document:
- Location
- Circuit
- Carrier
- Exact incident start time
- Incident end time
- Whether the entire site was affected
- Local gateway status
- Firewall status
- WAN interface status
- Carrier gateway status where available
- External connectivity
- Packet loss
- Latency
- Route information
- Whether the incident has happened before
The more precise your incident record, the easier it becomes for carrier support teams to correlate the event with their own systems.
Why Are Exact Timestamps So Important?
Carrier networks generate enormous amounts of data.
Saying:
"The internet was slow yesterday afternoon"
gives the provider an enormous investigation window.
Saying:
"The circuit began experiencing loss at 2:13:42 PM Central and recovered at 2:27:18 PM"
provides a much more useful correlation point.
Accurate timestamps allow the provider to investigate:
- Interface events
- Routing changes
- Circuit alarms
- Provider maintenance
- Equipment events
- Congestion
- Regional incidents
Time turns a complaint into an incident.
How Do You Rule Out the Local Network?
Test progressively outward.
Start with:
Local gateway
Then:
Firewall
Then:
WAN
Then:
Carrier gateway
Then:
External destinations
If packet loss already exists at the local gateway, investigate locally.
If the local gateway and firewall remain stable but external connectivity degrades, the failure domain shifts outward.
The goal is not to prove innocence.
It is to isolate where degradation begins.
How Do You Rule Out the Firewall?
Check:
- Firewall availability
- WAN interface
- LAN interface
- CPU
- Memory
- Interface errors
- Routing
- NAT
- SD WAN
- VPN status
- System logs
- Configuration changes
If the firewall remains healthy throughout the incident while upstream connectivity repeatedly fails, that becomes useful evidence.
What Does a Strong ISP Packet Loss Test Look Like?
Do not test only one destination.
Compare several points.
For example:
| Test Point | Packet Loss | | —- | —-: | | Local Gateway | 0% | | Firewall | 0% | | Carrier Gateway | 0% | | External Destination A | 6% | | External Destination B | 7% |
That is more informative than:
Google ping showed 7 percent loss.
Multiple independent tests help narrow the failure domain.
How Do You Use Ping When Troubleshooting an ISP?
Ping can help measure:
- Reachability
- Round trip time
- Packet loss during the test
Test multiple logical points.
A useful progression is:
Gateway → Firewall → Carrier Gateway → External Destination
Do not rely on one short ping test for an intermittent problem.
A circuit that fails for 30 seconds every two hours can easily appear perfect during a five minute troubleshooting session.
How Do You Use Traceroute When Troubleshooting an ISP?
Traceroute helps show the path traffic is taking.
It can help identify:
- Routing changes
- Unexpected paths
- Where latency appears
- Where responses stop
- Provider transitions
But interpret intermediate hops carefully.
A router that does not respond to traceroute probes may still forward production traffic normally.
Do not open a carrier ticket claiming:
"Hop 7 is dropping packets"
simply because Hop 7 displays asterisks.
Look at whether degradation continues through later hops and reaches the destination.
How Do You Use MTR to Troubleshoot an ISP?
MTR adds repeated measurements to route visibility.
It can help identify patterns involving:
- Packet loss
- Latency
- Route behavior
- Intermittent degradation
MTR can be particularly useful when the problem lasts long enough to collect repeated measurements.
But the same intermediate hop caution applies.
Loss displayed at one hop without corresponding loss farther down the path may reflect diagnostic traffic handling rather than production packet loss.
Can You Prove an ISP Problem with One Traceroute?
Usually not.
One traceroute is a snapshot.
Strong troubleshooting evidence comes from correlation.
Combine:
- Ping
- Traceroute or MTR
- Gateway monitoring
- Firewall monitoring
- Packet loss history
- Latency history
- Circuit availability
- Multiple destinations
- Exact timestamps
No single measurement needs to carry the entire diagnosis.
How Do You Prove Intermittent Packet Loss?
This is where continuous monitoring becomes particularly important.
Imagine packet loss occurs:
Monday: 2:14 PM to 2:19 PM
Tuesday: 1:52 PM to 2:01 PM
Wednesday: 2:07 PM to 2:13 PM
During each incident:
Local gateway: healthy
Firewall: healthy
External destinations: degraded
Now you have a pattern.
Patterns are much more difficult to dismiss as isolated user complaints.
How Do You Document High ISP Latency?
Compare incident latency against a historical baseline.
For example:
Normal latency: 22 ms
Incident latency: 185 ms
Duration: 17 minutes
Packet loss during incident: 4 percent
Firewall availability: normal
Gateway availability: normal
That tells a much stronger story than:
"The internet felt slow."
Why Does Historical Network Data Matter?
Because carrier troubleshooting is often retrospective.
By the time the carrier begins testing:
- Circuit is up
- Latency is normal
- Packet loss is gone
- Route has stabilized
Current state does not necessarily describe previous state.
Historical monitoring preserves evidence after the network recovers.
What Is an ISP SLA?
An SLA, or Service Level Agreement, describes service commitments associated with a business service.
Depending on the agreement, it may address items such as:
- Availability
- Performance
- Response
- Restoration
- Service credits
The actual terms vary significantly between providers and services.
Never assume a specific performance commitment exists without reviewing the applicable agreement.
How Do You Monitor an ISP SLA?
Maintain objective historical measurements relevant to the commitments in your agreement.
Depending on the service, that may include:
- Availability
- Outage duration
- Outage frequency
- Latency
- Packet loss
- Incident history
Compare your monitoring records with the actual contractual SLA.
Can Monitoring Data Help with SLA Credits?
Potentially, but monitoring data does not automatically establish entitlement to a service credit.
The provider's contract determines:
- What qualifies
- How performance is measured
- Required reporting procedures
- Claim deadlines
- Exclusions
- Credit calculation
Monitoring provides evidence that may support investigation or a claim.
Always review the actual carrier agreement.
What Should an ISP Escalation Include?
A strong escalation can include:
Customer: Example Company
Location: Branch 14
Circuit: Primary DIA
Incident Start: 2:13 PM Central
Incident End: 2:27 PM Central
Impact: Site wide external connectivity degradation
Local Gateway: Available
Firewall: Available
WAN Interface: Up
Packet Loss: 7 percent external
Normal Latency: 21 ms
Incident Latency: 164 ms
Recurrence: Similar events on previous two business days
Request: Investigate provider path and circuit telemetry during the incident window.
This is dramatically more actionable than:
"Please check our circuit. Users say the internet is slow."
What Should You Ask the ISP to Investigate?
Depending on the circumstances, ask the carrier to review the specific incident window for:
- Circuit alarms
- Interface errors
- Provider equipment
- Routing changes
- Congestion
- Packet loss
- Latency
- Maintenance
- Regional incidents
- Handoff events
Be specific.
Give them the evidence and timeframe.
Why Does the ISP Keep Closing the Ticket?
A common reason is that the provider tests the circuit after it has recovered and finds no active fault.
Improve the escalation by providing:
- Recurrence history
- Exact timestamps
- Monitoring graphs
- Packet loss history
- Latency history
- Firewall availability
- Gateway availability
- Multiple affected destinations
The goal is to shift the conversation from:
"Is it broken right now?"
to:
"Why did this condition repeatedly occur during these specific windows?"
How Can You Tell if the ISP Is Congested?
Possible indicators include:
- Recurring latency increases
- Packet loss during peak periods
- Performance degradation at similar times
- Healthy local network measurements
- Multiple external destinations affected
However, do not label a condition carrier congestion without sufficient evidence.
Use the data to identify the pattern and ask the provider to investigate the relevant portion of its network.
How Do You Know if the Problem Is Upstream from Your ISP?
Internet traffic can cross multiple networks.
A problem may exist:
- Inside your network
- At the carrier handoff
- Inside your ISP
- At a transit provider
- At a peering point
- Near the application provider
- At the destination itself
This is why testing multiple destinations and examining routes matters.
Not every problem beyond your firewall is necessarily your ISP's fault.
Technical credibility requires making that distinction.
What Is the Difference Between Evidence and Proof?
In network troubleshooting, this distinction matters.
One measurement may provide evidence.
Multiple independent measurements that repeatedly point toward the same failure domain create a much stronger technical case.
The objective should be:
Collect enough correlated evidence to identify the likely failure domain and enable the responsible provider to investigate it.
That is more useful than trying to assign blame prematurely.
Why Is 24/7 Monitoring Valuable for Carrier Management?
Because carrier problems do not wait for technicians.
A circuit may degrade:
- Overnight
- During lunch
- During a customer meeting
- For 45 seconds
- For seven minutes
- Every few days
Continuous monitoring gives IT teams a historical record even when nobody was actively testing.
The ADAM Pulse Approach to Carrier Troubleshooting
ADAM Pulse is designed to help answer:
Is the problem inside the customer network or beyond it?
Our gateway first diagnostic philosophy focuses on building context around incidents.
That means understanding:
Was the gateway available?
Was the firewall available?
Was the circuit responding?
When did degradation begin?
Was packet loss occurring?
Did latency increase?
How long did it last?
Has it happened before?
That evidence can dramatically improve troubleshooting and escalation.
From "Internet Is Slow" to an Evidence Based Carrier Escalation
Without monitoring:
User: Internet was terrible.
IT: Looks okay now.
ISP: Circuit tests clean.
Ticket: Closed.
With historical evidence:
IT: External packet loss began at 1:47 PM and persisted for 14 minutes. The gateway and firewall remained available. Latency increased from the normal 24 ms baseline to 173 ms. Similar events occurred Monday and Tuesday.
ISP: We have a specific incident window and pattern to investigate.
That is a fundamentally different support conversation.
Stop Arguing with Your ISP. Give Them Better Evidence.
The objective is not to prove the carrier wrong.
It is to get the problem fixed.
Accurate timestamps, historical monitoring, network baselines, packet loss data, latency measurements, and fault isolation give everyone involved a better starting point.
ADAM Pulse provides managed network monitoring designed to help multi site organizations understand network behavior before, during, and after incidents.
Know when it happened.
Know what remained online.
Know where degradation appeared.
Know whether it happened before.
Then escalate with evidence.
Learn more about ADAM Pulse and talk with USA Telecom about monitoring your internet circuits and network infrastructure.
Frequently asked questions
How Do You Know if Your ISP Is Causing a Network Problem?
Do not begin by assuming the carrier is responsible. Begin by isolating the network. Think of the path as:
Why Are Exact Timestamps So Important?
Carrier networks generate enormous amounts of data. Saying: gives the provider an enormous investigation window.
How Do You Rule Out the Firewall?
Check: If the firewall remains healthy throughout the incident while upstream connectivity repeatedly fails, that becomes useful evidence.
How Do You Use Traceroute When Troubleshooting an ISP?
Traceroute helps show the path traffic is taking. It can help identify: But interpret intermediate hops carefully.
How Do You Use MTR to Troubleshoot an ISP?
MTR adds repeated measurements to route visibility. It can help identify patterns involving: MTR can be particularly useful when the problem lasts long enough to collect repeated measurements.
Can You Prove an ISP Problem with One Traceroute?
Usually not. One traceroute is a snapshot. Strong troubleshooting evidence comes from correlation.
How Do You Prove Intermittent Packet Loss?
This is where continuous monitoring becomes particularly important. Imagine packet loss occurs: During each incident:
How Do You Document High ISP Latency?
Compare incident latency against a historical baseline. For example: Normal latency: 22 ms
Why Does Historical Network Data Matter?
Because carrier troubleshooting is often retrospective. By the time the carrier begins testing: Current state does not necessarily describe previous state.
What Is an ISP SLA?
An SLA, or Service Level Agreement, describes service commitments associated with a business service. Depending on the agreement, it may address items such as: The actual terms vary significantly between providers and services.
Sources
- IETF — RFC 792: Internet Control Message Protocol. Why devices may rate-limit or deprioritise the ICMP that ping and traceroute depend on.
- Cisco — Troubleshoot Packet Drops. Congestion, buffer exhaustion and interface errors as drop causes.
- Cisco — What Is Network Latency?
- FCC — Measuring Broadband America. Methodology for measuring latency and packet loss alongside throughput.
A single test from a single location at a single moment rarely proves where a fault sits. Correlate against history, test from more than one point, and preserve timestamped evidence before changing configuration or rebooting equipment.
USA Telecom Consulting LLC is a Service-Disabled Veteran-Owned Small Business running a 24/7 NOC. We monitor networks, circuits and firewalls for regulated and defense-supply-chain organizations.