An Alert is the raw notification your monitoring tools send in — distinct from an Alert Threshold rule (which defines when a metric should raise one) and distinct from an Incident (the ticket that may get created from it). Every alert has a name, a severity, a source, and whatever labels/annotations the sending tool attached, plus a link back to whichever incident and configuration item it ended up tied to, if any.
What happens automatically
Every incoming alert is checked, in order, before it's allowed to open a new ticket:
- A repeat notification for the exact same underlying problem is recognized and collapsed rather than treated as new.
- An alert on a CI inside an active maintenance window is suppressed automatically — no ticket at all.
- Your Event Rules are checked (see below) — a rule can suppress the alert outright, or correlate it into a sibling incident.
- If an incident is already open for this exact alert, the new firing is folded into it instead of creating a duplicate.
- If the matching incident was already closed and this is inside its post-resolution window, it's reopened instead of starting fresh.
- Before creating anything brand new, PulseServe checks whether an incident is already open on a related system elsewhere in the CMDB — not just the exact same one — and folds the alert into that if so.
- Only after all of that does a genuinely new incident get created and routed like any other.
That sixth step is the main defense against an alert storm: a failing dependency that trips alerts across a dozen related systems doesn't produce a dozen tickets, it grows one. As more distinct systems join that same incident, severity escalates on its own — see Cascade Detection & Major Incidents for exactly how that plays out and what it looks like on the ticket. When the monitoring tool later reports an alert resolved, the incident it caused is closed automatically too.
The Alerts page
Open Alerts to see every alert PulseServe has received, split into Firing, Resolved, and Suppressed — click a status chip to filter to it. Selecting an alert shows its full detail (labels, annotations, timestamps) and, if it caused one, a direct link to the incident it's tied to.
- Suppress alert — available on a firing alert; silences it without needing an incident to exist for it.
- Raise Problem — turns a recurring or noisy alert directly into a Problem, pre-filled from the alert's own data, and links its incident (if it has one) to that new Problem in the same step.
Event Rules — cutting down on noise before it reaches you
Settings → Routing → Event Rules lets you define, per alert name, how incoming alerts should be handled before they ever become tickets:
- Suppress — mute one alert while a related one is already firing on the same system (for example, don't bother ticketing disk pressure on a node that's already down).
- Correlate — fold a set of sibling alert names into whichever incident the first one already opened, within a time window you set, instead of spawning one incident per alert.
Rules run in the order you set them, first match wins. Each can be enabled/disabled or deleted without affecting the others.
Connecting your alerting tools
Alerts arrive from Alertmanager, a generic webhook, or inbound email — each set up the same way, from Admin → API Keys: issue a named key, copy the matching endpoint URL, and paste both into the sending tool's configuration. See Integrations for the full connection details.
Example
A flaky network switch fires a "PortFlapping" alert every few minutes for an hour. Without an event rule, that's a dozen near-identical incidents. An admin adds a Correlate rule folding repeat "PortFlapping" alerts on the same CI into the first incident within a 15-minute window — the next flapping episode produces one incident with a growing alert count on it, not a flood of duplicates.