May 11, 2026

HOW TO PROVE WIFI OUTAGES TO YOUR ISP (AND STOP GETTING BLAMED)

You call your internet provider. You explain that your connection drops three or four times a day. The agent puts you on hold for two minutes and then comes back to report that they've run a line test and everything looks fine. They suggest that you reboot your router. They mention that a technician visit costs $90 if no issue is found.

You hang up. The next day the WiFi drops three times again. You're starting to suspect that your ISP doesn't actually know what's wrong but has been trained to default-blame your equipment. You are correct.

The ISP has all the data. You have a vague memory that your Zoom froze at 10:14. That asymmetry is why every conversation ends with them blaming your router.

This is a guide to flipping the asymmetry. The trick is that ISP support is run on scripts, and the scripts have an exit branch for "customer provided concrete evidence." Most customers never reach that branch because they don't have evidence to provide. Once you do, the conversation changes immediately.

WHAT COUNTS AS EVIDENCE

ISP support agents are trained to dismiss four categories of complaint:

1. Vibe reports — "my internet has been bad lately." Nothing actionable. Easy dismissal.
2. Single incidents — "my video froze yesterday around 2 PM." Treated as one-off, brushed off as a fluke.
3. Speed-test screenshots — "I ran speedtest.net and got half my speed." Trivially explained by congestion, time of day, your device, your router, etc. Never wins.
4. Generic uptime claims — "my internet drops several times a day." Possibly true but unverifiable from their side. Met with "we don't see any outages on our end."

What actually works is a structured outage log with five fields per incident:

• Timestamp — precise time the outage began, with seconds. Helps correlate with their internal monitoring.
• Duration — seconds or minutes. Forces a measurable quantity into the conversation.
• Failure mode — "WiFi disconnected" vs "WiFi connected but internet unreachable." Critical distinction (more on this below).
• Frequency context — "this is the 4th outage today, 19th this week." Establishes pattern.
• Connection grade — a single letter (A through F) summarizing reliability over a rolling window. Compresses everything into one number the agent can't argue with.

THE CRITICAL DISTINCTION: WIFI DOWN VS INTERNET DOWN

This is the single most important data point. ISPs reject the majority of outage claims by deflecting to "your router or WiFi must be the problem." Your evidence must rule out that defense.

There are two distinct failure modes:

• WiFi connection lost. Your Mac is no longer associated with the access point. The WiFi icon shows empty bars. The cause is local: router rebooted, signal interference, hardware failure, etc.
• WiFi connection intact, internet unreachable. Your Mac is still associated with the access point at full signal strength — but the router cannot reach the internet beyond. This is almost always an ISP-side problem: their head-end equipment is down, a peering link failed, the modem-to-CMTS link hiccuped.

If your evidence shows category two (WiFi held, internet died), the ISP's "blame your router" script doesn't run. The router was demonstrably working. The failure is somewhere downstream of your home network. That is, by definition, their responsibility.

The Mac doesn't surface this distinction natively, but it's available via two Apple APIs: CoreWLAN tells you whether the WiFi connection is alive, and Apple's Network framework's NWPathMonitor tells you whether internet is reachable. When the first stays true and the second goes false, you have a category-two failure.

THE RECEIPT FORMAT THAT WORKS

After two years of arguing with ISP support, this is the format that consistently breaks through to a useful conversation:

What this format does, line by line:

• Header summary establishes that this is multi-day, multi-outage. Defeats the "this is just one fluke" dismissal.
• Connection grade D compresses 19 outages into a single number. Forces the agent to either accept the grade or argue with the methodology — both of which are improvements over "we ran a line test, everything looks fine."
• "WiFi held, internet unreachable" on every line preemptively defeats the "your router must be the problem" deflection.
• Pattern note at the bottom hints that this is correlated with their network conditions, not random.

Paste that into the support chat. Watch what happens to the agent's script.

HOW TO COLLECT THIS DATA ON A MAC

You have two options.

Option A: the manual way. Open a terminal and run something like:

This works. It's also: ugly, doesn't distinguish WiFi-down from internet-down, doesn't capture signal strength, doesn't survive a sleep/wake cycle, fills your disk over time, and produces output you have to manually post-process before it's useful. After a week of this, most people give up.

Option B: SignalDrop. A macOS menu bar app that does all of the above automatically. It catches every disconnect via Apple's CoreWLAN event API (zero polling, zero battery impact), distinguishes WiFi-down from internet-down via NWPathMonitor, stores everything in a local SQLite database, and exports the receipt format above with one click. The whole point of the app, honestly, was to skip Option A.

HOW TO USE THE RECEIPT IN A SUPPORT CHAT

Open the support chat. Skip the greeting pleasantries. First message:

"Hi — I've been tracking my internet outages for the past 7 days. 19 disconnects, 48 minutes of total downtime. In every case my Mac's WiFi connection itself held, but internet became unreachable. Here's the timeline:"

Then paste the receipt.

What you'll get back, in order of likelihood:

1. "Let me escalate this to our network team." This is the goal. Tier-1 has been bypassed.
2. "I can see service alerts in your area, I'll create a ticket." They saw your data, compared it to their internal monitoring, and found a match. You're not crazy.
3. "Have you tried rebooting your router?" They're following the script anyway. Reply: "The receipt shows WiFi held in every outage — the router was working. This is upstream from my equipment." Re-paste if needed.
4. "Our line tests don't show any outages." Reply: "Line tests run point-in-time, not retrospectively. The outages happened. I'd like to escalate to a network engineer who can pull historical data."

If after the second escalation nothing useful happens, ask for a service credit for documented downtime. Most ISPs will offer 5-10% of the monthly bill as a "courtesy credit" for documented outages. They're not legally obligated to in most jurisdictions, but the data makes it hard to refuse.

WHEN TO ESCALATE OUTSIDE THE ISP

If the receipt method doesn't move them, you have leverage tools beyond their support chat:

• FCC complaint (in the U.S., at consumercomplaints.fcc.gov). Free, takes about 10 minutes. ISPs are required to respond within 30 days. Attaching a multi-day outage log makes the complaint substantive rather than dismissible.
• State attorney general's consumer protection office. Most states have one. They love documented evidence of service-quality issues from ISPs.
• Your local public utility commission. Some states regulate telecom service quality.
• The Better Business Bureau. Less effective than government agencies but ISPs do respond because it affects their public rating.

In every case, the documented outage log makes the difference between "this customer is frustrated" and "this is a documented service failure." You need the data to access the leverage.

THE META POINT

ISP support is a script designed to defer, deflect, and dismiss the majority of customer complaints, because the majority of complaints aren't actionable. The script has an exit branch for actionable complaints — for customers who arrive with structured evidence. Most customers don't.

The whole point of SignalDrop is to make it trivial to be the customer who does.

Related: "Why your Mac silently drops WiFi (and how to catch it)" — the seven most common causes of Mac WiFi drops, with diagnostic steps for each. "Why I built SignalDrop" — the origin story behind this guide.