Intermittent multi-second latency spikes

I'm seeing intermittent multi-second latency spikes and failed connection attempts to external services, specifically on a hop inside Comcast's own
network — not at my modem/router, and not at the destination server. This is NOT a general "my internet feels slow" complaint: I have traceroute/mtr data
pinpointing the exact hop, and it happens while every other hop (including the destination) stays under 15ms.

The spikes are large enough (2-3 seconds of added latency) to break new outbound HTTPS connections from a service I run at home, even though basic
ping tests to the same destination often look completely clean — the problem is specific to new TCP connection setup, not general reachability,
so it's easy to miss with a quick ping check. Could you check for node congestion or a problem on the segment my account's node connects through?
The hop in question is a few hops past my gateway, still within Comcast's network, around the Seattle area (IPs 24.124.128.249, 96.110.44.86, 96.110.34.x below).

EVIDENCE: TCP (port 443) traceroute to a Cloudflare-hosted destination
--------------------------------
Captured 2026-08-29T08:23:14Z, 20 probes per hop, TCP SYN to port 443
(more representative of real application traffic than plain ICMP ping).

Hop  1  192.168.0.1 (my own gateway)
        loss 0%, avg 1.1ms, worst 1.3ms

Hop  2  10.27.176.114
        loss 0%, avg 11.8ms, worst 15.3ms

Hop  3  68.86.98.253
        loss 0%, avg 11.0ms, worst 15.2ms

Hop  4  96.216.61.81
        loss 0%, avg 12.5ms, worst 25.9ms

Hop  5  24.124.128.249
        loss 0%, avg 11.8ms, worst 20.1ms

Hop  6  24.124.128.249
        loss 0%, avg 11.7ms, worst 15.4ms

Hop  7  96.110.44.86 (and several sibling IPs on the same hop: 96.110.34.134,
        68.86.93.x, 96.110.44.90/82, 96.110.34.142/130 — normal load-balancing
        across parallel links, not a separate problem)
        loss 0%, avg 166.8ms, WORST 2089ms, stddev 506ms
        >>> THIS IS THE PROBLEM HOP — over 2 full seconds of latency on some
            probes, while hops 6 and 8 on either side of it stay under 15ms.

Hop  8  96.110.34.138 (+ sibling IPs, same load-balancing as hop 7)
        loss 50%, avg 12.2ms, worst 15.2ms

Hop  9  108.162.243.61 (+ sibling IPs — Comcast/Cloudflare peering boundary)
        loss 50%, avg 15.6ms, worst 23.6ms

Hop 10  108.162.243.45 (+ sibling IPs)
        loss 0%, avg 12.5ms, worst 21.6ms

Hop 11  162.159.137.232 (Cloudflare/Discord's edge — the destination)
        loss 20%, avg 11.5ms, worst 14.3ms

Notes on hops 8-10: these show partial "loss," but each probe returned a different IP (visible as multiple addresses per hop) — that's normal
load-balancing (ECMP) across parallel links at the Comcast/Cloudflare peering boundary, and routers there commonly deprioritize generating the
ICMP replies traceroute relies on without actually dropping real traffic. The meaningful finding is hop 7: a single, consistent latency spike deep
inside Comcast's own network, well before reaching Cloudflare.

ADDITIONAL EVIDENCE: repeated short bursts on a separate occasion
--------------------------------
Earlier capture (same hop, different time window) showed the same pattern:

Hop 6  24.124.128.249
       Run 1: avg 269ms, worst 3083ms
       Run 2 (minutes later): avg 123ms, worst 2064ms

Every other hop in both runs stayed under 25ms. This is not a one-off blip;
it recurs at this same point in the path across multiple independent
captures, at different times.

--------------------------------
A service I self-host at this address (discord bot) makes routine outbound HTTPS connections to Cloudflare-hosted infrastructure (discord.com). Around the
timestamps of these spikes, new outbound connections fail outright with a connect timeout, while already-established connections and basic ping
checks remain unaffected. This has been observed recurring at various points across multiple days (not a single isolated incident), including one
episode where the affected service was unable to establish an outbound connection at all for roughly 75 seconds straight.

--------------------------------
Please check for congestion, oversubscription, or a hardware issue on the node/segment serving my account (24.19.49.68), particularly around the
segment reached via 24.124.128.249 / 96.110.44.86 / 96.110.34.x. Happy to provide additional traceroute captures, modem signal-level stats, or run
tests at a specific time if that helps your team investigate.