Contributor
•
58 Messages
Recurring internet outages traced to Comcast's own infrastructure — data attached, requesting technician review
We've been experiencing recurring internet outages/degradation (several per day, each lasting seconds to minutes) for the past two weeks in our home in the Avenida España/Los Paseos neighborhood of San Jose. To get to the bottom of it, I used AI to set up continuous automated monitoring from a dedicated device on my home network, checking connectivity every 30 seconds and capturing traceroute diagnostics during every real outage.
Results over 72 hours of continuous monitoring (7,300+ checks):
- 99.30% uptime, 30 outage/degradation episodes, ~25.5 min confirmed downtime (note the downtime is VERY frequent short periods; not hours-long outages)
- My own equipment (Eero Pro 7 router) measures a clean 99.7%+ with sub-15ms latency — it is not the cause
- The problem is isolated to two specific points, both inside Comcast's network:
a. The local aggregation node immediately after my home connection (IP 100.92.201.194/195) — 3-4% failure rate, latency spikes up to 3.6 seconds (maybe even more, but this is what I managed to capture)
b. Comcast's own peering-edge equipment at the "9 Great Oaks" facility in San Jose (this facility is about 2.7 miles from our home on Phinney Way) — ~25-31% failure rate across 8 different router interfaces on what appear to be 2 physical devices
One recent 4-minute episode was captured in detail: 4 separate traceroutes over that window showed latency climbing from 1.3 to over 3.6 seconds, uniformly across the entire path, on both destinations tested — a sustained, escalating event, not a single bad measurement.
I have a full report (methodology, data tables, and raw traceroute captures) ready. Could someone from Xfinity Support take a look and arrange for the local aggregation node and the peering equipment at the 9 Great Oaks facility to be checked? Happy to provide account details via DM.
Internet Reliability Report — Prepared for Xfinity/Comcast Support
Account/Service Address: 7___ Phinney Way, San Jose, CA 95139
Report date: 2026-08-31
Monitoring period: 2026-08-28 17:25 to 2026-08-31 17:27 (~72 hours continuous, ongoing)
Executive Summary
Since deploying continuous automated monitoring on 2026-08-28, our home internet connection has experienced 30 distinct outage/degradation episodes in ~72 hours of observation — roughly one every 2-3 hours — totaling about 25.5 minutes of confirmed downtime (99.30% measured uptime). Our home Wi-Fi equipment (Eero Pro 7) was responsible for less than 1% of that and is not the cause.
The most recent episode (2026-08-31, 17:01-17:05) is the clearest evidence yet: a sustained 4-minute event during which we captured four separate traceroutes showing latency climbing from 1.3 seconds to over 3.6 seconds, uniformly across the entire path from Comcast’s first hop past our home all the way to the final destination, for both probe targets, the whole time (see Example Capture 1 below). This is not a single bad measurement — it is a sustained, escalating, repeatedly-confirmed event.
Using continuous latency monitoring and traceroute diagnostics (7,327 checks, 400+ traceroute captures), we have isolated the problem to two specific points, both inside Comcast’s own network, with everything else — our equipment and the destination networks — measuring clean:
- Node
100.92.201.194/100.92.201.195, the very first hop after our home gateway (Comcast’s local aggregation node). 3-4.4% failure rate and spikes up to 3.6 seconds of added latency. - Comcast’s own peering-edge equipment at their “9 Great Oaks” facility in San Jose —
Great Oaksis about 2.7 miles from hour home, so this is very likely the specific physical site serving our address, not a distant regional hub. Over the monitoring period we have observed 8 distinct router interfaces across what appears to be 2 physical devices at this facility (...-pe11and...-pe12, with 4 different bundle interfaces logged on each) all showing the same failure signature — this points at a shared uplink or capacity problem at the facility itself, not one bad piece of hardware. Failure rate at this point runs ~25-31%, independent of finding #1 (see Example Capture 3 below).
Every hop in between (Comcast’s own regional backbone, San Jose and Hayward routers) shows a clean 0% failure rate. Every hop after Comcast’s network (Cloudflare’s and Google’s own infrastructure) also resolves cleanly at the final destination the vast majority of the time. This isolates both problems squarely to Comcast’s local and regional infrastructure serving this account — not customer equipment, not Comcast’s broader network, and not any third party.
We are requesting a technician investigate (1) the local aggregation node/CMTS serving this account, and (2) the peering-edge capacity at the “9 Great Oaks” facility, which is in our immediate neighborhood.
Methodology
- Continuous automated monitoring from a dedicated always-on device on the home LAN (not a laptop or phone, which can sleep or move networks), checking connectivity roughly every 30 seconds.
- Each check independently measures: reachability to the home gateway, TCP reachability to two independent public providers (Cloudflare 1.1.1.1 and Google 8.8.8.8), a live HTTPS request, and DNS resolution.
- A reading is only logged as a real outage after being confirmed by a retry, filtering out one-off transient blips.
- When a real outage is detected, a traceroute is automatically captured to both 1.1.1.1 and 8.8.8.8, including an escalating retry (up to 60 seconds) on any hop that doesn’t respond — distinguishing “very slow” from “completely unresponsive.” During a sustained outage, new traceroutes are captured continuously (roughly every 1-2 minutes) for as long as the outage lasts, so we can see an event evolve rather than getting one static snapshot. Healthy-period baseline traceroutes are also captured every ~15 minutes for comparison.
- Traceroute latency is reported as time added over the previous hop, not cumulative round-trip time, and a hop only counts as a “failure” if it’s the first point of failure in that specific capture. This avoids the statistical error of blaming downstream hops for a problem that actually originated earlier in the path — a hop that only fails because an earlier hop already failed is excluded from its own statistics rather than penalized.
- Because our two probe targets (1.1.1.1, 8.8.8.8) diverge onto different physical infrastructure once they leave Comcast’s network, hops are also kept separate per destination rather than combined — combining them would incorrectly blend two unrelated third-party networks’ statistics together.
Overall period summary
| Metric | Value |
|---|---|
| Total checks | 7,327 |
| Uptime | 99.30% |
| Confirmed downtime | 25.5 min (~25 min WAN-related, <1 min Wi-Fi/local) |
| Outage episodes | 30 total (29 WAN-side, 1 local Wi-Fi — resolved on our end) |
Node-by-node reliability (400+ traceroute samples, split per destination past the divergence point)
| Hop | Node | Network | Samples | Mean added latency | Max added latency | Failure rate |
|---|---|---|---|---|---|---|
| 1 | Home gateway (192.168.4.1) | (ours) | 409 | ~2.7 ms | 16 ms | 0.2% |
| 2 (→1.1.1.1) | 100.92.201.194 | Comcast (local aggregation) | 203 | 225.2 ms | 3628 ms | 3.0% |
| 2 (→8.8.8.8) | 100.92.201.195 | Comcast (local aggregation) | 205 | 142.9 ms | 3321 ms | 4.4% |
| 3-7 | San Jose / Hayward / Santa Clara regional routers | Comcast (regional backbone) | 194-195 | 0.5-3.2 ms | 11-155 ms | 0.0-1.0% |
| 8 (→1.1.1.1) | be-36311-cs01.9greatoaks.ca.ibone.comcast.net | Comcast (“9 Great Oaks”, clean) | 194 | 0.7 ms | 18 ms | 0.0% |
| 9 (→1.1.1.1) | be-21xx/22xx/23xx/24xx-pe11/pe12.9greatoaks.ca.ibone.comcast.net (8 interfaces observed, see below) | Comcast (“9 Great Oaks” peering edge) | 194 | 2.4 ms | 39 ms | 30.9% |
| 8 (→8.8.8.8) | 142.251.254.209 | Google (third-party) | 195 | 39.3 ms | 2988 ms | 21.0% |
| 9 (→8.8.8.8) | dns.google (destination) | Google (third-party) | 195 | 0.8 ms | 14 ms | 0.0% |
| 10 (→1.1.1.1) | 172.68.188.x (varies) | Cloudflare (third-party) | 170 | 120.6 ms | 3791 ms | 25.3% |
| 11 (→1.1.1.1) | one.one.one.one (destination) | Cloudflare (third-party) | 195 | 13.0 ms | 1489 ms | 0.0% |
All 8 distinct router interfaces observed at hop 9 / the “9 Great Oaks” facility, across the full monitoring period (all showing the same failure pattern, all part of what appears to be 2 physical chassis, pe11 and pe12):
be-2111-pe11.9greatoaks.ca.ibone.comcast.netbe-2112-pe12.9greatoaks.ca.ibone.comcast.netbe-2211-pe11.9greatoaks.ca.ibone.comcast.netbe-2212-pe12.9greatoaks.ca.ibone.comcast.netbe-2311-pe11.9greatoaks.ca.ibone.comcast.netbe-2312-pe12.9greatoaks.ca.ibone.comcast.netbe-2411-pe11.9greatoaks.ca.ibone.comcast.netbe-2412-pe12.9greatoaks.ca.ibone.comcast.netNote on the two third-party rows (Google 142.251.254.209 and Cloudflare 172.68.188.x): these sit on Google’s and Cloudflare’s own networks respectively, past the point our traffic leaves Comcast, and are included here only for completeness/transparency. They are not something Comcast is responsible for. Their elevated failure/latency numbers in this table are largely a side effect of the same severe Comcast-side events documented below (traffic that’s already delayed 2-3+ seconds reaching Comcast’s peering edge is often delayed further reaching the final destination too) rather than an independent problem on Google’s or Cloudflare’s end.
Outage log (29 WAN-side episodes, most recent first)
| Start | Duration | Checks affected |
|---|---|---|
| 2026-08-31 17:10:13 | 30s | 1 |
| 2026-08-31 17:08:43 | 30s | 1 |
| 2026-08-31 17:07:53 | 30s | 1 |
| 2026-08-31 17:01:53 | 4m00s | 8 |
| 2026-08-31 15:04:59 | 30s | 1 |
| 2026-08-31 15:03:43 | 30s | 1 |
| 2026-08-31 11:12:38 | 30s | 1 |
| 2026-08-31 11:10:08 | 1m00s | 2 |
| 2026-08-31 11:08:20 | 30s | 1 |
| 2026-08-31 10:13:16 | 30s | 1 |
| 2026-08-30 21:01:00 | 30s | 1 |
| 2026-08-30 17:04:32 | 1m00s | 2 |
| 2026-08-30 17:01:31 | 30s | 1 |
| 2026-08-30 01:02:59 | 1m30s | 3 |
| 2026-08-30 00:23:15 | 30s | 1 |
| 2026-08-30 00:20:15 | 1m00s | 2 |
| 2026-08-29 23:04:31 | 1m30s | 3 |
| 2026-08-29 18:03:47 | 30s | 1 |
| 2026-08-29 17:59:47 | 30s | 1 |
| 2026-08-29 17:58:16 | 1m00s | 2 |
| 2026-08-29 17:54:00 | 30s | 1 |
| 2026-08-29 17:53:00 | 30s | 1 |
| 2026-08-29 17:51:30 | 1m00s | 2 |
| 2026-08-29 17:47:30 | 1m30s | 3 |
| 2026-08-29 17:43:27 | 30s | 1 |
| 2026-08-29 17:35:17 | 1m00s | 2 |
| 2026-08-29 17:33:27 | 30s | 1 |
| 2026-08-29 17:32:24 | 30s | 1 |
| 2026-08-29 14:39:37 | 1m00s | 2 |
Example capture 1 — a sustained 4-minute event, latency escalating in real time (2026-08-31, 17:01-17:05)
This is our strongest evidence: rather than one snapshot, we captured four traceroutes over the course of a single 4-minute outage, showing the severity climb and fluctuate while it was actively happening — proof this is a real, sustained network event, not measurement noise.
17:02:17 (target 1.1.1.1): hop 2 took over 1.3 seconds just to respond (confirmed via retry after the main pass’s 4-second window wasn’t even enough to catch it); by the time the path reached the destination, delay had grown to 3.5+ seconds.
17:02:55 (target 8.8.8.8), ~40s later:
traceroute to 8.8.8.8 (8.8.8.8), 15 hops max, 60 byte packets1 192.168.4.1 (192.168.4.1) 2.558 ms 2.527 ms2 100.92.201.194 (100.92.201.194) 1949.676 ms 100.92.201.195 (100.92.201.195) 1949.727 ms3 po-324-345-rur201.sanjose.ca.sfba.comcast.net (96.216.154.17) 1954.365 ms 1954.353 ms4 po-200-xar01.sanjose.ca.sfba.comcast.net (68.85.86.173) 1954.194 ms 1949.644 ms5 ae-199-rar01.santaclara.ca.sfba.comcast.net (68.87.226.109) 1949.605 ms 1949.572 ms6 be-399-ar01.hayward.ca.sfba.comcast.net (68.86.143.89) 1963.424 ms be-299-ar01.santaclara.ca.sfba.comcast.net (68.86.143.93) 1963.396 ms7 50.145.121.170 (50.145.121.170) 1963.401 ms 1963.354 ms8 172.253.73.211 (172.253.73.211) 1963.365 ms *9 108.170.235.209 (108.170.235.209) 1956.444 ms dns.google (8.8.8.8) 1956.393 msHome gateway: 2.5ms, normal. The instant traffic reaches Comcast’s aggregation node (hop 2), latency jumps to ~1.95 seconds and stays there, essentially flat, all the way to the actual destination (dns.google itself responds at 1956ms). The entire path was uniformly slow, both ends.
17:04:11 (target 1.1.1.1), ~2 minutes later — the peak:
traceroute to 1.1.1.1 (1.1.1.1), 15 hops max, 60 byte packets1 192.168.4.1 (192.168.4.1) 1.939 ms 1.835 ms2 100.92.201.195 (100.92.201.195) 3629.547 ms 100.92.201.194 (100.92.201.194) 3629.479 ms3 po-324-345-rur201.sanjose.ca.sfba.comcast.net (96.216.154.17) 3629.485 ms 3629.474 ms4 po-200-xar01.sanjose.ca.sfba.comcast.net (68.85.86.173) 3629.322 ms 69.139.199.85 (69.139.199.85) 3629.982 ms5 68.87.192.162 (68.87.192.162) 3629.306 ms 68.87.193.177 (68.87.193.177) 3638.266 ms6 be-399-ar01.hayward.ca.sfba.comcast.net (68.86.143.89) 3638.287 ms 3638.271 ms7 be-36311-cs01.9greatoaks.ca.ibone.comcast.net (68.86.93.129) 3638.267 ms 3638.438 ms8 be-2111-pe11.9greatoaks.ca.ibone.comcast.net (96.110.32.242) 3638.221 ms be-2412-pe12.9greatoaks.ca.ibone.comcast.net (96.110.33.46) 3638.182 ms9 be-2312-pe12.9greatoaks.ca.ibone.comcast.net (96.110.33.42) 3631.591 ms be-2111-pe11.9greatoaks.ca.ibone.comcast.net (96.110.32.242) 3631.541 ms10 * *11 172.68.188.22 (172.68.188.22) 2571.411 ms one.one.one.one (1.1.1.1) 2556.966 msNow 3.6 seconds, uniformly, from hop 2 all the way through the “9 Great Oaks” facility (hops 7-9) — both findings #1 and #2 visibly implicated in the same event. Destination still elevated at ~2.5-2.6 seconds.
17:04:43 (target 8.8.8.8), ~30s later: delay measured at 2.2 seconds, again uniform end-to-end.
Four measurements, four minutes, one continuous event, severity fluctuating between 1.3 and 3.6+ seconds the entire time. This behavior (uniform delay across the whole path, escalating and fluctuating over minutes) is characteristic of a saturated/oversubscribed link, not a single failing part.
Example capture 2 — aggregation node latency spike (2026-08-30 00:20:20, target 1.1.1.1)
traceroute to 1.1.1.1 (1.1.1.1), 15 hops max, 60 byte packets1 192.168.4.1 (192.168.4.1) 3.174 ms 3.158 ms2 100.92.201.194 (100.92.201.194) 1193.701 ms 1183.024 ms3 po-324-345-rur201.sanjose.ca.sfba.comcast.net (96.216.154.17) 1189.345 ms 1185.708 ms4 po-200-xar01.sanjose.ca.sfba.comcast.net (68.85.86.173) 1183.015 ms 1183.844 ms5 ae-199-rar01.hayward.ca.sfba.comcast.net (68.87.193.177) 1196.995 ms 1187.459 ms6 ae-199-rar01.hayward.ca.sfba.comcast.net (68.87.193.177) 1187.438 ms 1187.400 ms7 be-399-ar01.hayward.ca.sfba.comcast.net (68.86.143.89) 1196.983 ms 1187.387 ms8 be-2112-pe12.9greatoaks.ca.ibone.comcast.net (96.110.33.34) 1196.915 ms be-2311-pe11.9greatoaks.ca.ibone.comcast.net (96.110.32.250) 1196.890 ms9 * *10 172.68.188.83 (172.68.188.83) 283.488 ms *11 172.68.188.20 (172.68.188.20) 271.502 ms one.one.one.one (1.1.1.1) 269.728 msOur home gateway responds in 3ms, then every hop from 100.92.201.194 onward through Comcast’s own backbone (hops 2-8) shows ~1.18-1.20 seconds of latency, before dropping back to under 300ms once traffic reaches Cloudflare’s network (hops 10-11).
Example capture 3 — peering-edge failure, independent of the aggregation node (2026-08-30 13:33:07, target 1.1.1.1, routine healthy-period baseline capture)
traceroute to 1.1.1.1 (1.1.1.1), 15 hops max, 60 byte packets1 192.168.4.1 (192.168.4.1) 5.547 ms 5.532 ms2 100.92.201.194 (100.92.201.194) 18.023 ms 18.068 ms3 po-324-345-rur201.sanjose.ca.sfba.comcast.net (96.216.154.17) 25.304 ms 17.993 ms4 po-200-xar01.sanjose.ca.sfba.comcast.net (68.85.86.173) 26.774 ms 26.652 ms5 po-2-xar02.sanjose.ca.sfba.comcast.net (68.87.192.162) 17.905 ms ae-199-rar01.hayward.ca.sfba.comcast.net (68.87.193.177) 18.257 ms6 ae-199-rar01.hayward.ca.sfba.comcast.net (68.87.193.177) 18.332 ms 18.287 ms7 be-399-ar01.hayward.ca.sfba.comcast.net (68.86.143.89) 19.638 ms 27.275 ms8 be-2111-pe11.9greatoaks.ca.ibone.comcast.net (96.110.32.242) 19.595 ms 27.208 ms9 * *10 * *11 172.68.188.80 (172.68.188.80) 21.976 ms one.one.one.one (1.1.1.1) 19.958 msThis capture is notable precisely because everything up to hop 8 is completely healthy (~18-27ms, normal) — the aggregation node (finding #1) was working perfectly here. The failure starts fresh at hop 9, Comcast’s own peering-edge equipment at the “9 Great Oaks” facility, confirming this is a second, independent problem on Comcast’s infrastructure, not a downstream symptom of finding #1.
This monitoring is ongoing and additional data (including further traceroute captures with the escalating 60-second retry test) is available on request.
msabramo
Contributor
•
58 Messages
5 hours ago
And just now:
- A genuine ~6-minute sustained outage from 19:03-19:09 (worse than most of today's blips)
- It recovered briefly (~2 min), then flared again at 19:11:34
- Still flapping as of the last couple checks
1
0
msabramo
Contributor
•
58 Messages
3 hours ago
Something else I want to add to this. When we were having some less severe outages a few months ago, I purchased an Eero Pro 7 and a cellular backup unit and subscribed to Amazon's $100/year cellular backup service. The idea is that if primary Internet (Xfinity) goes out, then the Eero can automatically switch over to using this cellular connection so that there is slower but usable Internet.
Unfortunately the first time we starting have these kinds of outages, the Internet was down so often that the Eero burned through it's monthly quota of cellular data in a a few hours and then we were back to having no Internet.
My point is that these outages are happening so often for us that the cellular backup is useless. I'm trying to get across that in terms of impact this is not "It's a little slow" or it goes out for 5 minutes 2 or 3 times per day. This is my wife and I are running into problems so frequently that it's making it hard to get anything done. And we can't even rely on the backup because it's so bad that even the backup decided to quit.
0
0