Network path intelligence that tells you what broke, not just that something did.

Built for three teams that share one problem

Network path degradation is rarely a single team's problem and rarely has a clear owner when it happens. The network engineer gets paged but can't reach the ISP. The NOC manager needs evidence for a post-mortem but has only a latency graph. The SRE sees service SLOs eroding but can't determine if the fault is the application or the path it's running on.

The probe layer precision by design

The quality of everything downstream baselines, anomaly detection, BGP correlation, RCA depends entirely on the quality and accuracy of the probe data. NetPulse runs continuous, multi-mode probes every 5 seconds per target, and the probe configuration is designed to give you signal that matches your actual traffic, not a generic ping.

Four probe modes are available, each with distinct behavior and the right use case for each:

Live probe data three simultaneous probes to 1.1.1.1 TCP :443 · 5-min window · 29 probes each · AS7922 → AS13335

CS0 · DSCP 0

Best Effort

Quality4.5

Jitter (dest)31ms

Loss0%

PMTU1500B

AF41 · DSCP 34

Business

Quality5.0

Jitter (dest)29ms

Loss0%

PMTU1500B

EF · DSCP 46

Voice / Priority

Quality5.0

Jitter (dest)22ms

Loss0%

PMTU1500B

Destination jitter 1.1.1.1 (hop 12)

CS0 (best effort)

31ms

AF41 (business)

29ms

EF (voice / priority)

22ms

Hop	CS0 Best Effort	AF41 Business	EF Voice / Priority
1	192.168.4.1  identical across all three probes
2	96.120.73.81  AS7922 (Comcast)
3–7	24.124.227.113 → 96.108.142.17 → 96.216.138.141 → 96.216.138.137 → 68.85.35.37  all AS7922
8	96.110.42.45ECMP	96.110.42.33ECMP	96.110.42.41ECMP
9	96.110.33.254	96.110.33.246	96.110.33.250
10	no reply	no reply	no reply
11	162.158.61.113 AS13335 · jitter 16ms	162.158.61.117 AS13335 · jitter 18ms	162.158.61.125 AS13335 · jitter 20ms
12	1.1.1.1 · 31ms jitter · Q 4.5	1.1.1.1 · 29ms jitter · Q 5.0	1.1.1.1 · 22ms jitter · Q 5.0

QoS gradient is real jitter drops in step with priority class

CS0 (best effort) arrives with 31ms jitter and a quality score of 4.5. AF41 (business) drops to 29ms and a quality score of 5.0. EF (voice/priority) reaches 22ms a 29% jitter reduction over best effort. The quality difference at the destination is measurable and consistent with Comcast (AS7922) honoring DSCP markings via priority queuing.

ECMP diverges at hop 8 paths are not identical

Hops 1–7 are identical across all three probes. At hop 8, inside AS7922's backbone, each traffic class is load-balanced onto a different set of Comcast routers and reaches a different Cloudflare edge node at hop 11. The DSCP value combined with the connection's 5-tuple is influencing ECMP path selection. The jitter difference reflects a combination of QoS treatment and path-specific characteristics; the two effects are not fully separable from this data alone. Note: "no reply" at hop 10 is the filtered AS7922/AS13335 peering boundary it inflates the 8% avg-loss headline but represents no real packet loss on the path.

CS0 · Best Effort

AF41 · Business

EF · Voice / Priority

AI-learned baselines anomaly detection without the noise

Every probe mode feeds into the same baseline engine. For each probe target and each hop, NetPulse maintains P5, P50, and P95 latency baselines across 672 time-of-day buckets 96 fifteen-minute slots per day, seven days per week, rolling 14-day window. Your 2:47 AM Thursday baseline is distinct from your 2:47 PM Thursday baseline. Your Monday morning rush-hour baseline is distinct from Saturday.

Anomaly detection runs two algorithms in parallel:

Z-score on every event (~100ms): Each probe reading is compared to the current time-slot P95. If deviation exceeds 2 standard deviations, it's flagged as a candidate.

PELT change-point detection on 30-second micro-batches: PELT (Pruned Exact Linear Time) looks for statistically significant inflection points in the recent latency time series distinguishing a sustained shift in the distribution from single-packet noise. This is the filter that eliminates ~85% of false positives that threshold-based systems would page on.

# Tier 2  PELT confirms sustained deviation, not transient spike
def check_pelt(recent_latencies: list[float]) -> bool:
    model = rpt.Pelt(model="rbf").fit(np.array(recent_latencies))
    breakpoints = model.predict(pen=3)
    # Change-point in last 4 readings = sustained shift in distribution
    return len(breakpoints) > 1 and breakpoints[-2] > len(recent_latencies) - 4

An anomaly is confirmed only when both conditions hold for more than 90 seconds. Only then does the system publish to the anomaly pipeline and trigger BGP correlation. This 90-second window is deliberate: it eliminates transient micro-congestion events that self-resolve and would otherwise generate alert fatigue.

BGP correlation upstream intelligence, automatically

The single most common explanation for a mid-path latency spike that has no internal cause is a BGP routing change. When an upstream AS changes its route advertisements rerouting traffic through a different exchange point, a longer AS path, or a geographically distant peer the latency impact appears immediately in your probe data. But without correlating that probe data against the BGP event stream, you have a spike with no explanation.

NetPulse ingests continuous BGP UPDATE and WITHDRAW streams from RouteViews (University of Oregon) and RIPE RIS (RIPE NCC) via BGPStream. Every BGP event affecting every monitored prefix is stored and indexed. When a probe anomaly is confirmed:

1. The destination IP is resolved to its BGP prefix
2. The BGP events table is queried for that prefix in a ±10-minute window
3. If a BGP UPDATE is matched, the anomaly is classified upstream_routing with the AS path before and after the change
4. The affected AS, the new AS path, and the BGP event timestamp are attached to the RCA context

Beyond route changes, NetPulse also detects BGP hijacks when a new origin ASN begins advertising a prefix you monitor. This alert fires immediately on detection, does not wait for a probe anomaly to correlate, and is delivered at the highest priority through all configured channels. An unexpected origin ASN is a security event, not just a routing event.

Automated RCA from anomaly to answer in under 60 seconds

Probe data, baseline deviation, BGP correlation, cross-tenant peer scope, and hop stability are assembled into a structured context and passed to the Claude API. The LLM is given a strict instruction: return structured JSON only. No prose essays, no hedging paragraphs. The JSON is rendered directly into the RCA card:

Total time from anomaly onset to RCA card rendered: approximately 41 seconds. The 90-second confirmation window is the dominant factor by design. The BGP correlation lookup takes <200ms against ClickHouse. The LLM call adds 2–4 seconds.

The RCA card is pushed simultaneously to the dashboard timeline (as a clickable anomaly band), the Slack alert (as a rich message with all tags), and the PagerDuty incident (in the description field). The engineer who gets paged receives the diagnosis in the same notification that woke them up before they've opened a laptop.

What this looks like for each team

For Network Engineers

The 3 AM page is the same. What changes is the 45-second read after it. By the time you open your laptop, NetPulse has already correlated the probe spike against the BGP feed, determined whether the degradation is internal or upstream, checked how many peer networks on the same ISP are affected, and written a recommended action. You either confirm "not us, monitoring" and go back to sleep or you see "INTERNAL · hop 2 · your AS" and know exactly where to start.

The BGP evidence stack UPDATE timestamp, prefix, old and new AS paths, peer count is already formatted for an ISP escalation. You don't write it from your incident notes at 4 AM. You copy it from the RCA card.

For Network Operations / NOC

The dashboard gives leadership a real-time network health view without requiring an engineer to translate it on a call. Every confirmed incident is stored with its full RCA summary classification, duration, peer scope, resolution timestamp. MTTR metrics are not self-reported; they're calculated from the anomaly detection and resolution timestamps in ClickHouse. The weekly digest surfaces the pattern: which targets degraded, which ISPs were responsible, how long before each resolved.

For SREs

When a service latency SLO is breaching, the first question is always: is this the application or the infrastructure? NetPulse answers the network half of that question with precision. A TCP Force SYN probe to the affected service's port shows whether the network-layer RTT is elevated. If it is, and it correlates with a BGP route change at hop 4, you've ruled out the application in under two minutes and you have the routing evidence to share with the network team. If the network RTT is nominal, the fault is in the application layer, and you stop investigating infrastructure.

DSCP probing adds another dimension for SREs managing real-time traffic. If your voice or video service degrades and DSCP probing shows EF latency converging with CS0 latency at a carrier hop, you've identified a QoS failure at the infrastructure level not a bug in your application.

The before and after

The network event is the same. The difference is in what happens to your team while it's occurring.