How to Prove Your ISP Is Causing an Intermittent Internet Problem

By Michael Obraitis, Managing Partner, and Michael Dale, CEO · Published September 8, 2026 · Last reviewed September 2026 · ADAM Pulse Knowledge Base · Network Operations Series

Intermittent internet problems are among the hardest network issues to troubleshoot. The connection drops. Users complain. Applications disconnect. Voice calls break up. VPN tunnels reset. Then, ten minutes later, everything works again. You call the Internet Service Provider. The carrier tests the circuit and responds: “Everything looks fine from our side.” They may be correct at that exact moment. That does not prove the circuit was healthy when the problem occurred. To successfully escalate an intermittent ISP problem, you need to transform: “The internet keeps dropping.” into: “At 10:42:17 AM the primary WAN experienced 38 percent packet loss, gateway response failed for 74 seconds, the firewall and LAN remained healthy, the backup connection remained reachable, and the same event occurred four times during the previous 48 hours.” That is evidence. And evidence changes the carrier conversation.

Short answer

How Do You Prove Your ISP Is Causing an Internet Problem?

You usually cannot prove ISP responsibility from a single speed test or ping. Instead, build a body of evidence that isolates the problem to the carrier path. Capture:

• Exact outage timestamps
• ISP gateway availability
• Packet loss over time
• Latency over time
• Jitter where relevant
• WAN interface state
• Public IP reachability
• Tests to multiple external destinations
• DNS results
• Firewall health
• LAN health
• Backup ISP status
• Traceroute or MTR results
• Recurrence history
• Carrier trouble ticket numbers
• Business impact

The strongest case shows: The local network remained healthy while connectivity through the ISP repeatedly failed. That is much stronger than simply telling the carrier: “Our internet is slow.”

Why Are Intermittent Internet Problems So Difficult to Diagnose?

An intermittent problem disappears. That means the evidence can disappear with it. When the carrier technician investigates later: The modem may be online. The gateway may respond. Packet loss may be zero. Latency may be normal. The optical signal may look acceptable. The circuit may pass a basic test. But none of those observations necessarily describe what happened at 9:17 AM when 40 employees were disconnected. This is why continuous measurement is so important. Microsoft's current troubleshooting guidance for transient connectivity specifically recommends repeated connection testing and measuring dropped connections and latency rather than relying on a single point in time test.

The First Rule: Do Not Start by Trying to Prove the ISP Is Wrong

This is important. Do not approach troubleshooting with the assumption: “The carrier is definitely the problem.” Your objective is to determine the failure domain. Possible causes include: ISP Firewall Router DNS LAN WiFi VPN Power Cloud service Application Endpoint Configuration If you begin with a predetermined conclusion, you can waste hours escalating the wrong organization. The goal is: Collect enough independent evidence that the carrier path becomes the most likely source of the failure.

What Evidence Actually Helps Prove an ISP Problem?

Think in layers. For an ISP escalation, you ideally want to establish: Local network health The internal network continued functioning. Firewall health The edge device remained responsive and operational. WAN failure Connectivity through the carrier degraded or disappeared. Independent destination failures Multiple external destinations experienced the same problem. Recurrence The failure happened repeatedly rather than once. Timing Exact timestamps can be correlated with carrier logs. Recovery Service returned without changes to your internal network. Those together tell a compelling story.

Step 1: Record Exact Timestamps

This sounds simple, but it is extremely important. Do not record: “Internet went down this morning.” Record: 10:42:17 AM Eastern and: 10:43:31 AM Eastern Carriers can search logs much more effectively when given a precise window. Record: Outage start Recovery time Duration Timezone Every recurrence Example: Incident Start End Duration

1 10:42:17 AM 10:43:31 AM 74 sec

2 1:16:42 PM 1:17:09 PM 27 sec

3 4:08:11 PM 4:10:04 PM 113 sec

Now you have a pattern.

Step 2: Continuously Monitor the ISP Gateway

One of the most useful targets is the ISP next hop or gateway. Monitor: Reachability Packet loss Latency Response consistency If users lose internet connectivity at exactly the same time the carrier gateway stops responding, that is useful evidence. However, be careful. Some carriers rate limit or deprioritize ICMP. That means a gateway occasionally failing to respond to ping does not automatically prove service failure. The strongest evidence uses multiple signals.

Step 3: Test Multiple External Destinations

Do not rely on one target. A remote destination can have its own problem. Monitor several independent destinations. For example: Carrier gateway Public DNS service Cloud endpoint Your own hosted endpoint Another public internet destination If only one destination fails, suspect that destination or route. If several unrelated destinations fail simultaneously while the local network remains healthy, the upstream network becomes more suspicious.

Step 4: Measure Packet Loss

Packet loss occurs when network packets do not successfully reach their destination. Some applications tolerate small amounts better than others. Real time services such as: Voice Video conferencing Remote desktop VPN Cloud applications can be especially sensitive. Microsoft notes that packet loss can reduce network performance and cause higher level applications or APIs to fail. Do not capture only: Current packet loss: 0 percent Capture packet loss over time. Example: 9:00 AM: 0% 9:15 AM: 0% 9:17 AM: 32% 9:18 AM: 67% 9:19 AM: 4% 9:20 AM: 0% That is far more useful.

Step 5: Measure Latency

Latency is the time it takes traffic to travel between two points and return. A circuit can remain technically online while latency becomes high enough to make applications unusable. Track: Normal baseline Average latency Peak latency Time of day Outage correlation Example: Normal: 18 to 25 ms Incident: 187 to 630 ms Recovered: 21 ms That pattern tells a very different story from: “Internet seemed slow.”

Step 6: Measure Jitter

Jitter describes variation in packet delay. It is particularly important for: VoIP Zoom Teams Contact centers Video Real time communications Cisco has long treated delay, jitter, and packet loss as core measurements for evaluating network performance for voice and other time sensitive applications. A circuit may show acceptable average latency while extreme variation creates terrible call quality.

Step 7: Monitor the WAN Interface

Capture whether the WAN interface: Remained up Went physically down Flapped Renegotiated Lost DHCP Lost PPPoE Changed public IP Lost routing Changed speed or duplex A physical link transition is especially useful evidence. For example: 11:04:12 WAN1 link down 11:04:19 WAN1 link up 11:04:29 DHCP lease restored That is a very different incident from application level packet loss.

Step 8: Confirm the Firewall Remained Healthy

Before blaming the ISP, verify the firewall. Check: CPU Memory Sessions Routing NAT Interfaces HA state System uptime Reboots Configuration changes Errors If the internet failed but the firewall: Stayed powered Stayed reachable locally Had normal CPU Had normal memory Did not reboot Had no configuration changes and continued passing traffic through a secondary ISP, that significantly strengthens the case that the problem is upstream of the firewall.

Step 9: Compare Primary and Backup Internet

This is one of the most powerful isolation tests available. Suppose the network has: WAN1: AT&T WAN2: Comcast During the incident: AT&T gateway fails AT&T external probes fail Comcast remains healthy Firewall remains healthy LAN remains healthy Traffic successfully moves to Comcast Then AT&T recovers without internal changes. That is very strong evidence that the issue is associated with the primary WAN path. Multi-WAN comparison is one of the strongest isolation tests because knowing one WAN failed is much more useful when monitoring simultaneously proves the other path and local infrastructure remained healthy.

Step 10: Compare Wired and Wireless Users

You do not want to spend three hours fighting with an ISP only to discover the real problem is WiFi. Test: Ethernet and WiFi If wired users are healthy while WiFi users experience problems: Investigate: Access points RF interference Wireless controller Authentication WiFi VLAN PoE DHCP not the ISP. Microsoft similarly recommends isolating wired and wireless connectivity when troubleshooting Internet access because the local access method itself can be the source of the failure.

Step 11: Rule Out DNS

Another common mistake is escalating an ISP outage when DNS is failing. Test: Public IP connectivity and Hostname resolution If: IP connectivity succeeds but: DNS resolution fails the underlying internet path may still be healthy. Document: Configured DNS server Lookup result Lookup response time Alternative resolver result Internal vs public resolution

Step 12: Use Traceroute Carefully

Traceroute can help show the path traffic takes and where latency begins to increase. AWS recommends traceroute or MTR for diagnosing network latency and route behavior, and notes that MTR provides an especially useful continuously updated picture of packet loss and round trip time across hops. But traceroute requires interpretation. A common mistake is: Hop 7 shows 80 percent packet loss. Therefore hop 7 is broken. Not necessarily. Some routers deprioritize or rate limit responses to diagnostic traffic while continuing to forward customer traffic normally. The more meaningful pattern is: Loss begins at a hop and persists through subsequent hops to the final destination. Even then, combine it with other evidence.

Step 13: Use MTR for Intermittent Problems

MTR combines aspects of: Ping and Traceroute and continuously measures the route over time. This makes it useful for intermittent problems. AWS specifically recommends MTR for analyzing packet loss and latency because it allows performance to be observed continuously across each hop in the path. A useful evidence package might include: 100 probes 500 probes Several minutes of testing Tests during both healthy and unhealthy periods That gives you something to compare.

Step 14: Test From Both Directions When Possible

Internet paths are not always symmetrical. Traffic going: Office → Cloud may take a different path than: Cloud → Office. AWS explicitly recommends gathering trace results in both directions when troubleshooting VPN and routing problems because the path may differ depending on direction. This is especially useful when you control: A cloud server Another branch A monitoring platform A hosted probe

Step 15: Test From Multiple Vantage Points

This can dramatically strengthen your case. Suppose your public WAN address becomes unreachable. Test from: Local firewall Cloud probe Another branch External monitoring service Remote server If several independent monitoring locations simultaneously lose reachability while your firewall remains locally healthy, the evidence becomes much stronger.

Step 16: Establish a Healthy Baseline

You cannot effectively prove degradation without knowing what normal looks like. Establish typical: Latency Packet loss Jitter Throughput DNS response Gateway availability Application performance Example: Normal Latency: 21 ms Packet loss: 0% Jitter: 4 ms Incident Latency: 319 ms Packet loss: 28% Jitter: 147 ms The deviation becomes obvious.

Step 17: Look for Patterns by Time of Day

Recurring time patterns can be extremely informative. Example: Every weekday: 8 AM to 10 AM: healthy 11 AM: latency rising 12 PM to 3 PM: packet loss 5 PM: healthy again That may suggest: Congestion Capacity Oversubscription Traffic patterns Provider backbone issues Local utilization Do not immediately assume carrier oversubscription. Compare internal interface utilization first.

Step 18: Rule Out Your Own Bandwidth Saturation

Suppose your 100 Mbps circuit reaches: 99 Mbps while packet loss and latency spike. The ISP may not be faulty. Your organization may simply be saturating the connection. Check: Inbound utilization Outbound utilization Top talkers Backups Cloud synchronization Video Large transfers Security cameras Guest WiFi Software updates Traffic shaping A clean carrier escalation should show that the degradation occurred without local saturation, if that is true.

Step 19: Review Interface Errors

Check both internal and external interfaces for: CRC errors Drops Discards Collisions where relevant Input errors Output errors Negotiation issues If errors occur between: Firewall and carrier handoff the physical layer may be involved. Possible causes include: Cable SFP Optics Fiber Carrier NID Speed or duplex mismatch Dirty fiber Failing interface This is why saying simply: “The ISP is dropping packets” can sometimes be too broad. The actual issue could be the handoff between your equipment and theirs.

Step 20: Correlate User Complaints With Telemetry

User complaints become much more valuable when tied to measurements. Example: 2:12 PM Reception reports calls breaking up. Monitoring shows: Packet loss 11% Jitter 102 ms Latency 240 ms 2:16 PM Accounting reports cloud app disconnect. Monitoring shows: Packet loss 34% 2:19 PM WAN gateway unreachable. Now the user complaints reinforce the technical data.

Step 21: Capture Failover Events

If a backup circuit exists, record: Exact failover time Primary failure Backup activation VPN restoration Public IP change Application recovery Return to primary Example: 3:41:07 WAN1 degradation begins 3:41:24 WAN1 declared unavailable 3:41:31 WAN2 active 3:41:46 VPN restored 3:42:03 application tests healthy This isolates the primary connection and documents the operational effect.

Step 22: Capture Recurrence

A one time outage can be difficult to diagnose. Repeated identical incidents create a pattern. Document: How often How long

Same time of day?

Same gateway?

Same route?

Same symptoms?

Same restoration pattern?

Example: 13 outages in 7 days is considerably more actionable than: “It drops sometimes.”

Step 23: Keep Every Carrier Ticket Number

Create a history. For example: Date Carrier Ticket Duration Finding

Aug 28 INC827321 3 min No trouble found

Aug 30 INC831107 8 min No trouble found

Sep 2 INC842761 12 min Escalated

Sep 4 INC849310 6 min Regional issue

Sep 6 INC855103 9 min Engineering review

Now the problem has history. That can help justify escalation beyond first level support.

Step 24: Do Not Reboot Everything Before Capturing Evidence

This is a common mistake. Internet becomes unstable. Technician reboots: Modem Firewall Switch Then the connection returns. Now nobody knows whether: The ISP recovered The modem was faulty The firewall was faulty The reboot changed state DHCP renewed Routing changed You have destroyed part of the evidence. When operationally safe: Capture state first. Then remediate. Obviously, restoring service remains the priority during serious incidents.

Step 25: Ask the Carrier the Right Questions

Do not simply ask: “Is there an outage?” Ask specific questions such as:

Did the carrier gateway flap at these timestamps?

Did the access device lose sync?

Were there optical alarms?

Were there interface errors?

Was the circuit reprovisioned?

Were there maintenance events?

Were other circuits on the same equipment affected?

Did the carrier observe packet loss?

Did the provider see routing changes?

Are there capacity concerns on the serving infrastructure?

Can engineering review the historical logs for the exact timestamps?

Specific questions encourage deeper investigation.

What Is Strong Evidence That the ISP Is the Problem?

No single signal is always conclusive. But a strong pattern might look like this: During the outage Firewall locally reachable Firewall CPU and memory normal LAN healthy WiFi healthy No configuration changes Primary ISP gateway unreachable Multiple public destinations unreachable through primary ISP Backup ISP fully operational Users recover when traffic fails over Primary connection later recovers without customer network changes Same event repeats over multiple days That is compelling isolation evidence.

What Is Weak Evidence?

Examples include: “My Zoom call sounded bad.” “Internet felt slow.” “One ping dropped.” “Speedtest was low once.” “Google loaded slowly.” “The firewall says WAN down.” “All my devices alerted.” Each observation can be useful. None alone proves carrier responsibility.

Does a Speed Test Prove My ISP Is Bad?

No. A speed test measures performance between your device and a particular test endpoint at that moment. Results can be affected by: WiFi Local congestion Endpoint performance Browser Firewall inspection VPN Test server Distance Internet routing Other users consuming bandwidth A low speed test can be evidence. It is not automatically proof of ISP failure.

What Is More Important Than a Speed Test?

For intermittent outages, continuous measurements are often much more useful: Gateway availability Packet loss Latency Jitter Interface state Path changes Failover events Outage duration Recurrence The problem is usually reliability, not merely headline bandwidth.

Can Packet Loss Prove the ISP Is at Fault?

Packet loss proves that packets are not successfully reaching the destination. It does not automatically identify who caused the loss. Microsoft notes that simultaneous traces from both ends can help identify whether packets disappear somewhere between source and destination. To assign responsibility, isolate where the loss begins and rule out: LAN Firewall Endpoint Local saturation Cloud destination Other intermediate networks

Can Traceroute Prove Which ISP Hop Is Broken?

Sometimes it can provide important evidence, but traceroute should not normally be treated as proof by itself. Intermediate routers can: Rate limit responses Ignore diagnostic packets Respond slowly while forwarding normal traffic correctly. Look for persistent effects extending to the final destination and correlate them with other telemetry.

How Long Should You Monitor an Intermittent Internet Problem?

Long enough to capture the problem. That could mean: 24 hours 7 days 30 days or longer depending on recurrence. For a problem occurring twice per day, several days may reveal a clear pattern. For a problem occurring twice per month, longer monitoring is needed. This is why always on monitoring is substantially more useful than troubleshooting only after someone complains.

What Should an ISP Escalation Package Include?

This is where the evidence becomes actionable. A carrier ready report should include: Circuit Information Carrier Circuit ID Location Public IP Service type Bandwidth Incident Summary What users experienced Exact Timeline Start and recovery times Frequency Number of incidents Packet Loss Baseline and incident values Latency Baseline and incident values Jitter Where relevant ISP Gateway Availability during incident WAN Interface State and transitions Firewall Health during incident LAN Health during incident Backup Circuit Status and performance Trace Evidence Traceroute or MTR where useful Business Impact Users and applications affected Previous Carrier Tickets Historical incident numbers Supporting Evidence Graphs Screenshots Logs Monitoring output The result should make it easy for carrier engineering to investigate. Example ISP Escalation Subject Recurring intermittent packet loss and gateway failure, circuit ABC12345 Location Tampa, Florida Carrier Example Fiber Problem Primary internet connection has experienced repeated short duration failures during the previous seven days. Latest Incident September 7 10:42:17 AM to 10:43:31 AM Eastern Monitoring Evidence Packet loss peaked at 67% Latency increased from 22 ms baseline to 418 ms Carrier gateway became unreachable Three independent public destinations failed Firewall remained locally reachable Firewall CPU and memory remained normal LAN remained operational No configuration changes occurred Secondary ISP remained fully reachable Traffic successfully transitioned to WAN2 Primary circuit recovered without internal intervention Recurrence 11 similar incidents during previous seven days. Business Impact VPN sessions reset. Zoom calls disconnected. Cloud applications experienced session loss. Request Please escalate to carrier engineering and review access equipment, interface statistics, optical levels, routing events, and historical alarms corresponding with the attached timestamps. That is a much stronger escalation than: “Internet keeps dropping. Please check.”

What If the ISP Still Says Everything Is Fine?

Ask for escalation. Provide: Repeated timestamps Graphs Carrier ticket history Independent probe results MTR Gateway loss Failover correlation Business impact Then ask the carrier to review historical data, not simply current circuit state. If the pattern continues, request deeper review by: Network engineering Access engineering Field operations Carrier NOC Account team Escalation management depending on the provider.

What If the ISP Blames Your Firewall?

Do not argue. Test the hypothesis. Ask:

Did the firewall remain locally reachable?

Did WAN2 remain operational through the same firewall?

Did the firewall reboot?

Were resources normal?

Did configuration change?

Did other services through the firewall continue working?

If the backup ISP continued operating through the same firewall while only one WAN path failed, that is relevant evidence.

What If the ISP Blames WiFi?

Again, test. Compare: Wired vs. Wireless. If both failed simultaneously and carrier path monitoring also showed packet loss: WiFi becomes less likely. If only wireless users were affected: The carrier may be correct. Good troubleshooting is about isolation, not winning an argument.

What If the Problem Is Really the Cloud?

Suppose: ISP gateway healthy Multiple public destinations healthy DNS healthy VPN healthy Only Microsoft 365 fails Then investigate Microsoft 365. Similarly, if only: Zoom Salesforce Azure AWS Google Workspace or another service fails, check the application provider before escalating the ISP. Root Cause Confidence Levels When documenting findings, use confidence language. Confirmed ISP Failure Carrier acknowledges fault or physical issue. Highly Probable ISP Failure Multiple independent signals isolate the failure to the carrier path. Probable ISP Failure Evidence strongly suggests upstream trouble but no carrier confirmation exists. Suspected ISP Failure Some evidence exists, but competing causes remain. This makes reports more credible. Do not say: “The ISP definitely caused this” when the available evidence only supports: “The primary carrier path is the most probable failure domain.” The ADAM ISP Evidence Model The ideal monitoring workflow is: DETECT Something changed. ↓ ISOLATE

ISP, firewall, DNS, VPN, LAN, WiFi, or cloud?

↓ CORRELATE

Which measurements changed together?

↓ COMPARE Primary vs backup, local vs external, wired vs wireless. ↓ DOCUMENT Capture timestamps and evidence. ↓ ESCALATE Generate carrier ready evidence. ↓ VERIFY Confirm provider findings and restoration. ↓ MONITOR Determine whether the incident returns. ADAM Pulse is designed to help turn those measurements into a carrier-ready incident dossier. When the ISP says the circuit is fine, send them the evidence: outage start and end, packet loss, latency, jitter, gateway availability, public IP status, failover activity, historical performance, incident recurrence, graphs, carrier ticket numbers, and SLA impact. That turns monitoring telemetry into something operationally useful. Example ADAM Pulse Incident Summary Instead of: WAN1 Packet Loss Alert a useful monitoring record looks like: Recurring Primary WAN Degradation Location: Tampa Carrier: Frontier Circuit: ABC12345 Incident: 11 of previous 7 days Start: 10:42:17 AM Duration: 74 seconds Peak Packet Loss: 67% Peak Latency: 418 ms Carrier Gateway: Unreachable Firewall: Healthy LAN: Healthy Backup WAN: Healthy Failover: Successful Recent Changes: None Probable Fault Domain: Frontier access network Confidence: High Recommended Action: Carrier engineering escalation That is much closer to the information a technician needs. ISP Troubleshooting Evidence Checklist IDENTIFY ☐ Carrier ☐ Circuit ID ☐ Location ☐ Public IP ☐ Service type TIMESTAMP ☐ Start time ☐ Recovery time ☐ Duration ☐ Timezone MEASURE ☐ Packet loss ☐ Latency ☐ Jitter ☐ Throughput ☐ WAN state TEST ☐ Carrier gateway ☐ Multiple external targets ☐ DNS ☐ Traceroute ☐ MTR ☐ Wired connection VERIFY LOCAL NETWORK ☐ Firewall healthy ☐ LAN healthy ☐ WiFi compared ☐ CPU normal ☐ Memory normal ☐ No unexpected reboot ☐ No recent change COMPARE ☐ Primary vs backup ISP ☐ Internal vs external ☐ Wired vs wireless ☐ Healthy period vs incident ☐ Multiple vantage points DOCUMENT ☐ Graphs ☐ Screenshots ☐ Logs ☐ User reports ☐ Previous tickets ESCALATE ☐ Carrier ticket opened ☐ Exact timestamps supplied ☐ Engineering review requested ☐ Business impact documented MONITOR ☐ Continue testing ☐ Record recurrence ☐ Confirm permanent resolution

Frequently asked questions

How can I prove my ISP is dropping my connection?

Continuously monitor the carrier gateway and multiple independent destinations, record exact outage timestamps, packet loss and latency, and compare those measurements with firewall, LAN, and backup ISP health. The strongest evidence isolates the failure to the carrier path while showing local infrastructure remained healthy.

Why does my ISP say everything looks fine?

The circuit may be healthy when the provider tests it. Intermittent problems can disappear before troubleshooting begins. Historical monitoring lets you show what happened during the actual incident.

What should I monitor to prove an intermittent ISP issue?

At minimum, monitor ISP gateway availability, packet loss, latency, WAN interface state, several public destinations, firewall health, and backup connectivity.

Does packet loss mean my ISP is bad?

Not automatically. Packet loss can occur in the LAN, firewall, ISP, intermediate networks, or destination. You must isolate where the loss originates.

Is ping enough to prove an ISP outage?

No. Ping is useful, but some devices rate limit ICMP. Combine ping with multiple targets, interface state, application tests, MTR, traceroute, and other telemetry.

Is traceroute enough to prove where the problem is?

Usually not by itself. Intermediate hops can deprioritize diagnostic traffic. Persistent problems reaching subsequent hops and the final destination are more meaningful, especially when supported by other measurements.

What is MTR?

MTR combines continuous reachability testing with route information, making it useful for analyzing intermittent packet loss and latency over multiple network hops. AWS recommends it for diagnosing packet loss and latency across network paths.

Can a speed test prove an ISP problem?

A speed test can provide evidence, but it is a single measurement affected by many factors. Continuous reliability monitoring is generally more useful for proving intermittent outages.

How do I know if the problem is my firewall or the ISP?

Compare local firewall health, ISP gateway reachability, primary and backup WAN paths, and external probes. If the firewall and backup circuit remain healthy while only the primary path fails, the primary ISP becomes a stronger suspect.

How do I know if WiFi is causing the problem?

Test a wired device. If Ethernet remains stable while only wireless devices experience problems, investigate WiFi before escalating the carrier.

How long should I collect evidence?

Long enough to capture multiple examples of the issue. Depending on frequency, that may be hours, days, weeks, or longer.

What should I send my ISP when escalating?

Provide circuit information, exact timestamps, outage duration, packet loss, latency, gateway status, firewall and LAN status, backup ISP status, recurrence history, trace data where useful, graphs, screenshots, previous ticket numbers, and business impact.

Can my monitoring platform automatically create an ISP evidence report?

A monitoring platform can collect much of the required telemetry automatically. ADAM Pulse is designed to help turn those measurements into a carrier-ready incident dossier.

Bottom line

You usually do not prove an intermittent ISP problem with one test. You prove it by building a consistent body of evidence. The strongest case demonstrates: WHEN the failure occurred WHAT measurements changed WHERE the failure appears to begin WHAT remained healthy WHETHER another ISP path continued working

HOW often the failure has occurred

WHAT business services were affected The key principle is: Do not send your ISP another complaint. Send them evidence. Traditional monitoring might tell you: Packet loss detected. A more useful system tells you: Primary ISP degradation detected. Local infrastructure remained healthy. Backup connectivity remained stable. Eleven matching incidents occurred during the previous seven days. Here is the evidence package for carrier engineering. That is monitoring transformed into action.

Related articles

• How to prove your ISP is causing packet loss or outages
• How to troubleshoot intermittent internet outages
• Is it the ISP or the firewall?
• How to file an ISP SLA credit claim
• How to monitor your ISP SLA

← More from the ADAM Pulse Knowledge Base

Prepared by ADAM Pulse (USA Telecom Consulting LLC) — managed AI governance, network, and NOC services. Support: (888) 989-4872 · support@adampulse.us