Cascade Detection & Major Incidents

How PulseServe tells the difference between fifty unrelated alerts and one incident with fifty symptoms.

A single failing dependency can trip dozens of alerts within seconds — every service downstream of it starts complaining at once. Treated as fifty separate tickets, that is fifty pages, fifty investigations, and fifty engineers duplicating the same root-cause work.

The Signal Correlator recognizes this pattern before it reaches a human. It maps incoming alerts — more than twenty pattern types spanning CPU, memory, database, network, security, and availability — into structured categories, then walks the CMDB dependency graph to compute blast radius: how many downstream configuration items are actually at risk, stratified by how critical each one is.

Grouping and escalation

Before a new incident is even created, PulseServe checks whether an active incident already exists on a related system elsewhere in the CMDB dependency graph — not just the exact same one. If it finds one, the new signal is folded into that existing incident instead of opening a separate ticket, and the reviewer sees active upstream and downstream incidents surfaced directly on it, so they can immediately tell whether they're looking at the source of a failure or one of its symptoms.

This is what actually links incidents together as parent and child — the same relationship, and the same Duplicates tab, used by manually marking one incident a duplicate of another (see Incident Tools & Collaboration). A cascading incident is auto-adopted as a child of the closest related incident upstream, walking up toward whichever one is the true root cause; once a root is established, downstream incidents get auto-adopted as its children too. You'll see the identical "linked to parent incident" badge and "Child" tag either way — cascade linking isn't a separate concept from duplicate linking, it's the same mechanism triggered automatically instead of by hand.

As distinct systems keep joining the cluster, severity escalates automatically: two or more distinct affected systems bumps the incident to critical, and three or more auto-declares a Major Incident. That threshold is deliberately conservative, because escalating too eagerly recreates the alert fatigue this is meant to solve.

The result is a queue where one real outage shows up as one incident with full context — not as an inbox full of alerts everyone has to individually rule out.

Triaging a cascade in the context graph

Open the incident's Context Graph tab and count the red and amber nodes (see CMDB & Blast Radius for what each color means). If four or more critical CIs are affected, treat it as a P1 and coordinate a bridge call. Fix the red-bordered root CI first, then confirm downstream CIs recover on their own before touching them individually — that's usually faster than working the symptoms in parallel.

Running a major incident

Once an incident is declared major — automatically by cascade escalation, or manually by anyone who judges it warrants one — a dedicated Major Incident panel opens on the ticket. From there you can assign an incident commander, attach a conference-bridge link for the response call, and track affected business services alongside the technical CIs.

Updates go out on a running timeline aimed at three different audiences — internal responders, business stakeholders, and customers — each getting only the level of detail appropriate for them. A configurable cadence flags when an update is overdue, so a major incident can't quietly go quiet. If the fix needs a change that can't wait for normal CAB review, the commander can create an emergency change directly from the panel, pre-linked to the incident. Standing the incident down requires a closing summary.

Active and recently resolved major incidents also appear on a public status page reachable from the self-service portal, each showing the latest customer-facing update — useful for pointing affected users somewhere other than your support queue during a live outage.

Example

A core network router's BGP session drops after a firmware update. Within seconds, a dozen incidents fire across multiple data centres. The Context Graph on any one of them shows twelve red and amber nodes all tracing back to the same router — PulseServe groups them into a single cascade and auto-escalates to major-incident handling. An incident commander is assigned, a bridge link goes out to the response team, and customer-facing updates start posting to the status page. RCA identifies the firmware update as the cause; the commander creates an emergency change directly from the panel for the rollback, executed once approved.