Diagnosing ISP Throttling Using Continuous Ping Monitoring

What ISP Throttling Actually Is

Throttling is when your Internet Service Provider deliberately slows your connection. Not because their network is overwhelmed, but because they chose to. It’s a policy decision, not a capacity problem, and the distinction matters enormously when you’re trying to figure out why your connection degrades every evening like clockwork.

There are several distinct types, and they require different detection strategies:

Congestion vs. Throttling

This is the critical distinction. Genuine network congestion is a gradual curve: latency slowly rises as more neighbors come online in the evening, peaks around 9 PM, and gradually recedes. Throttling is a step change: latency jumps sharply at a specific time, as if someone flipped a switch, and drops back just as sharply. If your monitoring data shows a cliff edge rather than a hill, that’s a red flag.

Why Speed Tests Don’t Catch It

Speed tests are structurally poor at detecting throttling. Ookla’s server list is publicly available and its traffic handshakes are identifiable, making it straightforward for ISPs to recognize and prioritize speed test traffic. Many ISPs host their own Speedtest.net servers, meaning the test may never leave the ISP’s own network, measuring internal capacity rather than real-world internet performance.

The Institute for Local Self-Reliance (ILSR) has documented cases where Speedtest.net reported 6–9 Mbps upstream while real-world uploads achieved only 2.5–3 Mbps. This is a well-documented structural concern: speed tests measure your connection under artificial, best-case conditions that may not reflect how your ISP handles your actual traffic.

The Legal Landscape in 2026

This matters for understanding what your ISP is and isn’t allowed to do. The FCC voted to reinstate net neutrality rules in April 2024, but the Sixth Circuit Court of Appeals unanimously vacated that order on January 2, 2025 (Ohio Telecom Association v. FCC), applying the Supreme Court’s Loper Bright ruling that ended Chevron deference. The rules never took effect.

At the federal level, there are currently no net neutrality rules. ISPs may throttle, block, or engage in paid prioritization, provided they disclose these practices in their terms of service. FCC Chairman Brendan Carr is opposed to net neutrality regulation, and no federal restoration is expected.

State laws are the real protection. California’s SB-822 (upheld by the Ninth Circuit in ACA Connects v. Bonta) is the strongest, banning throttling and paid prioritization outright. Washington (HB 2282), Oregon, Colorado, Maine, New Jersey, and Vermont have enacted their own net neutrality laws with varying levels of enforcement. If you live in one of these states, your ISP is subject to stricter rules than federal law requires, and your state attorney general has authority to enforce them.

The Symptoms

Throttling rarely announces itself. You won’t see an error message or a notification. Instead, you’ll notice patterns, subtle at first, then maddening once you start paying attention:

• Time-of-day spikes. Your connection works flawlessly from 6 AM to 6 PM, then degrades sharply between 7–11 PM every weekday. This is the single most common throttling symptom. The consistency of the timing is the giveaway: real congestion fluctuates; throttling is predictable.
• Service-specific drops. Netflix buffers constantly, but web browsing and email feel normal. YouTube stutters, but Speedtest.net shows 300 Mbps. When only certain services degrade while the underlying connection appears healthy, application-based throttling is a strong possibility.
• Scheduled packet loss. Zero packet loss all day, then 2–5% packet loss during prime-time hours. Your packet loss monitoring shows a pattern that repeats with eerie regularity.
• “It works fine in the morning.” This is the classic throttling complaint. You call your ISP, they run a test at 10 AM, everything looks perfect. They close the ticket. By 8 PM, the problem is back. Without continuous monitoring data, you have no evidence that the problem exists at all.
• Mid-billing-cycle degradation. Your connection is fast at the start of the month and progressively slows. If you’re on a plan with a data cap (even one labeled “unlimited”), check whether the timing correlates with your data usage reaching a threshold.

Before assuming the worst, rule out local causes. Wi-Fi interference can mimic throttling symptoms, and macOS itself can cause periodic latency spikes from Sequoia’s firewall behavior. The evidence-gathering method below helps you systematically eliminate these possibilities.

The Evidence-Gathering Method

Suspecting throttling isn’t enough. You need data: timestamped, continuous, and unambiguous. Here’s the five-step process for building an evidence case.

Step 1: Establish a Baseline

Run continuous monitoring for at least 48 hours during a period when your connection feels normal, typically weekday mornings or overnight. Record your average latency, jitter, and packet loss to a reliable external target like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). This establishes what your connection should look like when it’s not being throttled.

Step 2: Run a 7-Day Monitoring Session

Keep your monitoring tool running continuously for a minimum of seven days. You need to capture multiple complete daily cycles, both weekdays and weekends, to distinguish a real pattern from a one-time event. The longer the monitoring window, the stronger the evidence.

Step 3: Identify Patterns

With a week of data, look for three specific pattern types:

• Time-of-day correlation. Does latency climb every evening between the same hours? A consistent 7–11 PM degradation across multiple days is the strongest throttling indicator.
• Day-of-week patterns. Are weekends worse than weekdays, or vice versa? Some ISPs apply different throttling policies based on overall network load, which varies by day.
• Sudden step changes. Does latency jump from 20ms to 80ms at exactly 7:00 PM, or does it gradually climb from 20ms to 50ms over two hours? The sharp cliff edge suggests a deliberate policy kicking in. The gradual curve suggests genuine congestion.

Step 4: Rule Out Local Causes

Before blaming your ISP, systematically eliminate everything on your end:

• Check for background downloads: Time Machine backups, iCloud sync, macOS software updates, and cloud storage services all generate traffic that can cause latency spikes.
• Test on Ethernet to eliminate Wi-Fi variability. If the pattern disappears on a wired connection, the problem is your wireless environment, not your ISP.
• Disable any active VPN to rule out VPN server congestion as the cause.
• Check if other devices on your network are consuming bandwidth during the degradation window.
• Distinguish your symptoms from bufferbloat. Latency that spikes only when your own network is under load is a local problem, not ISP throttling.

Step 5: Run a VPN Comparison Test

This is the most informative single test, but it requires careful interpretation. Connect to a VPN and monitor latency to the same target (e.g., 1.1.1.1) during the hours when you normally see degradation. If your latency spikes at 8 PM without the VPN but stays stable through the VPN, that suggests your ISP is treating your unencrypted traffic differently.

Important caveats:

• VPNs add baseline latency from encryption overhead. If latency is actually lower through a VPN during peak hours, that’s a very strong signal. If it’s roughly the same, the result is inconclusive.
• Use a geographically nearby VPN server to minimize the added latency from routing through a distant server.
• Genuine network congestion affects VPN traffic equally, since VPN packets still traverse the same last-mile infrastructure. If a VPN eliminates the spike entirely, that points more strongly to targeted throttling than to congestion.
• Pinging 1.1.1.1 uses ICMP, which ISPs may treat differently from TCP or UDP application traffic. Supplement the ping test with application-specific measurements: use Fast.com (which measures Netflix-type traffic) alongside Speedtest.net and M-Lab’s speed test to compare results across different traffic types.
• Test on a wired connection and repeat across multiple days. A single VPN test on one evening is one data point, not proof. Present this as one piece of evidence in a broader diagnostic toolkit.

Reading the Data: What Throttling Looks Like

Once you have a week or more of continuous monitoring data, the patterns tell the story. Here’s how to read them.

The Cliff Edge Pattern (Throttling)

The hallmark of throttling is a sharp, sudden transition. Your latency holds steady at 18–22ms all day, then jumps to 70–90ms at almost exactly the same time every evening. The transition takes minutes, not hours. The return to baseline is equally abrupt, often occurring at midnight or 1 AM when the throttling window ends. If you overlay multiple days, the transitions line up like they were drawn with a ruler.

The Gradual Curve (Congestion)

Genuine congestion looks different. Latency begins rising around 5–6 PM as people come home from work. It peaks gradually around 8–9 PM. It recedes slowly through the late evening. The curve is organic, asymmetric, and varies in severity from day to day. Monday might peak at 60ms; Friday at 90ms. There’s no precise switch-on or switch-off time.

Periodic Spikes (Not Throttling)

Some patterns look alarming but have local causes. Brief latency spikes every 30–60 seconds that last only a packet or two are often caused by AWDL channel hopping on your Mac, where your Wi-Fi radio briefly switches channels for AirDrop discovery. Latency that spikes only when you’re uploading or downloading is bufferbloat, not throttling. And erratic jitter that appears across all hours rather than on a schedule points to Wi-Fi interference or local congestion, not ISP policy.

Packet Loss as a Throttling Indicator

Throttling doesn’t always manifest as increased latency. Some ISPs manage congestion by dropping packets rather than queuing them. If your packet loss data shows 0% during the day and 2–5% during peak hours, consistently and across multiple days, that’s a pattern worth investigating. Combined with the latency data, it builds a more complete picture.

What to Compare Against

Your baseline data from Step 1 is the anchor. Any deviation from baseline that occurs on a consistent schedule and cannot be explained by local factors (Wi-Fi, background processes, your own network load) is evidence worth documenting. The stronger the contrast between baseline and peak-hour performance, the stronger the case.

Building Your Case

Data without documentation is just numbers on a screen. To get results, whether from your ISP, the FCC, or a state attorney general, you need to present your evidence clearly and systematically.

Document Everything

• Export monitoring reports with timestamps. Your continuous monitoring data is the foundation. Export it in a format that shows date, time, latency, jitter, and packet loss for every measurement. A graph showing 14 consecutive days of the same pattern is hard to argue with.
• Run multiple speed tests during peak and off-peak hours. Use different tools: Ookla (speedtest.net), Fast.com (Netflix), M-Lab (speed.measurementlab.net), and Cloudflare (speed.cloudflare.com). If Ookla reports 300 Mbps during the same hour that Fast.com reports 25 Mbps, that discrepancy itself is evidence. ISPs may optimize for some speed test providers but not others.
• Screenshot everything. Timestamps matter. A screenshot of your dashboard at 10 AM showing 18ms latency alongside a screenshot at 9 PM showing 85ms latency tells the story at a glance.
• Log your VPN comparison results. Side-by-side data from VPN and non-VPN tests during the same degradation window is among the most compelling evidence you can present.

File an FCC Complaint

Consumers can file informal complaints through the FCC Consumer Inquiries and Complaints Center online portal. Once filed, your ISP has 30 days to respond directly to you, with a copy to the FCC. If you’re unsatisfied with the response, you can submit rebuttal information, which triggers another 30-day response cycle.

A formal complaint is a separate, more serious process that costs $500 or more and is essentially a legal proceeding. For most consumers, the informal complaint is the right starting point.

Be honest about the current landscape: with federal net neutrality rules struck down in January 2025, the FCC has limited authority to act on throttling complaints specifically. The complaint is most effective when framed around contractual or disclosure violations: your ISP promised certain speeds in its terms of service and isn’t delivering them. Even with limited enforcement authority, many consumers report that filing an FCC complaint gets the ISP’s attention faster than calling customer service. The ISP knows the complaint creates a paper trail.

Contact Your ISP with Specific Data

When you call your ISP, don’t say “my internet is slow at night.” Say: “My latency to 1.1.1.1 averages 18ms from 6 AM to 6 PM but jumps to 75ms from 7 to 11 PM. This pattern has repeated for 14 consecutive days. I have timestamped data and I’ve ruled out local causes by testing on Ethernet with no other devices active.”

Specificity changes the conversation. A vague complaint gets a scripted response. A data-driven complaint with timestamps, methodology, and export files gets escalated to a network engineer who can actually investigate.

What You Can Do About It

Rule Out DNS Issues

Switch your DNS to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) in System Settings → Wi-Fi → Details → DNS. This won’t fix throttling, but it eliminates DNS resolution problems as a confounding factor and ensures you’re not relying on your ISP’s DNS servers, which may themselves be deprioritized during peak hours.

Use a VPN for Traffic-Type Throttling

If your evidence suggests application-based throttling (specific services degraded while others stay fast), a VPN encrypts your traffic so the ISP can’t identify what you’re doing. This is effective against content-based and protocol-based throttling. Be aware that a VPN adds baseline latency and cannot help with congestion-based or data cap throttling, since your traffic still traverses the same last-mile infrastructure and your total data usage remains visible to your ISP.

Switch ISPs

If you have the option, vote with your wallet. Check what’s available at your address. Fiber providers generally have fewer congestion and throttling issues than cable. In many areas, unfortunately, there’s only one viable broadband option, which is precisely why throttling persists as a problem.

Demand a Technician Visit

Come armed with your monitoring data. A technician who sees two weeks of timestamped evidence showing a consistent degradation pattern can test your line during the affected hours and escalate internally. Without data, you’ll get the standard “everything looks fine from our end” response.

Escalate

If your ISP won’t resolve the issue, you have several escalation paths, roughly in order of effectiveness:

• State attorney general. This is often the most effective path, especially if you live in a state with net neutrality laws. Multiple state AG offices, including Oregon, Minnesota, New York, North Carolina, and Maine, explicitly accept broadband and ISP complaints. In states with net neutrality laws (California, Washington, Oregon, Colorado), AGs have stronger authority to act. State AGs generally handle patterns of complaints, but enough individual complaints from the same ISP can trigger a formal investigation.
• FCC complaint. As described above, this is useful as leverage even with limited enforcement authority. The 30-day response requirement creates accountability that a phone call doesn’t.
• Local franchise authority. This is a real but increasingly limited option. Franchise authorities primarily oversee cable television service, not broadband-only ISPs. As providers shift to fiber and fixed wireless, franchise authority relevance is diminishing. The name of your local franchise authority should appear on your cable bill. Worth trying, but set expectations accordingly.

Frequently Asked Questions