Can I suppress alerts during planned maintenance?

Yes — maintenance windows can be scheduled on any service or service group, and they automatically suppress matching alerts for the configured duration.

Will dependency mapping create false positives?

It does the opposite — when a parent service is unhealthy, child-service alerts are *suppressed* (with a note in the timeline) so on-call only pages once for the real cause.

How are duplicates detected?

Each rule + target combination produces a stable fingerprint. Re-firings against the same fingerprint roll into the open incident as a counter; they don't create new pages.

FeaturesAlerting

Alerting

An alert engine that respects on-call sleep.

Suppression rules, grouping, dedupe and flapping detection that work because they were designed into the reducer — not stitched on top of a webhook.

Book a demo See pricing

<5s

Median detect-to-alert

Per-incident

Fingerprint dedupe

Window + label + dependency

Suppression dimensions

Storm-prone webhook chains

Custom alert rules

Multi-condition thresholds compose with AND/OR semantics — and every rule lists exactly which monitors it covers before you save.

Threshold rules — latency > X for N consecutive checks
Boolean rules — status code outside allowlist for N checks
Compound conditions joined with AND / OR
Per-rule routing — different rule severities → different channels
Dry-run preview before activation

Alert grouping & correlation

When a shared dependency goes down, we open one incident with N attached services — not N pages to the same human.

Group by service-group, region or custom label
Correlation window — events within N minutes roll into one incident
Per-group routing decisions (page the group oncall, not every owner)
Auto-expand grouping when more services join the incident

Structured suppression

Three dimensions — windows, labels and dependencies — combine to keep the noise out without blanketing real failures.

Time-window suppression (e.g. nightly maintenance batch)
Label-based suppression (e.g. environment=staging)
Dependency-based — child alerts suppressed when parent is down
Maintenance windows automatically suppress matching services
Per-suppression-rule audit trail

Flapping detection

Endpoints that bounce up-down-up-down don't generate ten pages — we identify the pattern and surface it as a single warning incident.

Configurable flap threshold (state changes per window)
Flapping state surfaced on the service detail page
Optional auto-suppression while in a flapping state
Flap history retained for postmortem analysis

Service dependency mapping

Declare what depends on what. The reducer reads the graph and rolls health upstream — so a DB outage doesn't generate twelve unrelated pages.

Service-to-service dependency declaration
Upstream / downstream health roll-up
Visual dependency graph on each service page
Cycle detection at save time

Fingerprinting & deduplication

Identical alerts collapse into one incident with a counter — your on-call sees the truth, not the volume.

Stable per-rule + per-target fingerprint
Dedupe across re-checks until the incident closes
Counter on the incident showing how many times the alert refired
Audit trail of each individual firing

Alerting vs the market

How we stack up on alerting

Only rows relevant to this capability. See the full comparison →

Feature	AlertifyPro	Datadog	UptimeRobot	Pingdom
Structured suppression (window + label + dependency)
Alert fingerprinting / dedupe
Service dependency mapping with roll-up
Flapping detection out of the box
Maintenance auto-suppression

Frequently asked

Ready to see alerting on your stack?

Spin up your first monitor in under a minute. Free forever for the first 5 services.