Skip to main content
Alert suppression prevents notifications from firing during planned maintenance or when a higher-level resource group incident is already active. Suppressed incidents are still created and tracked — only the notifications are silenced.

​
Suppression types

DevHelm supports two independent suppression mechanisms:

​
Maintenance window suppression

When a monitor has an active maintenance window with suppressAlerts: true:
  • No notification policies are evaluated for that monitor’s incidents
  • Incidents are still created with severity MAINTENANCE
  • Check results continue to be recorded
  • Once the maintenance window ends, normal alerting resumes
Maintenance windows can be scoped to a single monitor or applied organization-wide.

​
Resource group suppression

When a resource group has suppressMemberAlerts enabled and the group has an active group-level incident:
  • Member monitor alerts are suppressed
  • Individual monitor incidents are still created and tracked
  • The group-level incident serves as the single source of truth
  • When the group incident resolves, member alerting resumes
This prevents alert storms when multiple monitors in a group fail simultaneously due to a shared root cause.

​
Suppression precedence

When multiple suppression conditions apply, the following order determines behavior:
  1. Maintenance window — checked first; if active with suppressAlerts: true, notifications are immediately suppressed
  2. Resource group suppression — checked next; if the monitor’s group has an active incident with suppression enabled, notifications are suppressed
  3. Normal evaluation — if neither condition applies, notification policies are evaluated normally

​
What gets suppressed

AspectSuppressedNot suppressed
Notification policy evaluationYes—
Escalation chain executionYes—
Channel deliveryYes—
Incident creation—No — incidents are still created
Check execution—No — checks still run
Check result recording—No — results are stored
Incident timeline—No — timeline entries still appear

​
Viewing suppression state

You can determine why an incident didn’t generate notifications by checking:
  • Maintenance windows: List active windows covering the monitor
curl "https://api.devhelm.io/api/v1/maintenance-windows?monitorId=<monitor-id>&filter=active" \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN"
  • Notification dispatches: An incident with no dispatches during an active maintenance window indicates suppression
curl "https://api.devhelm.io/api/v1/notification-dispatches?incident_id=<incident-id>" \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN"

​
Common patterns

​
Deployment suppression

Create a short maintenance window around deployments to suppress alerts during rollout: 
devhelm maintenance-windows create \
  --starts-at "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --ends-at "$(date -u -d '+30 minutes' +%Y-%m-%dT%H:%M:%SZ)" \
  --reason "Production deployment"

​
Infrastructure group

Group all monitors for a shared dependency (e.g., a database cluster) into a resource group with suppression. When the database is down, you get one group alert instead of individual alerts for every service that depends on it.

​
Scheduled weekly maintenance

Use recurring maintenance windows with an iCal RRULE: 
{
  "startsAt": "2026-04-15T02:00:00Z",
  "endsAt": "2026-04-15T04:00:00Z",
  "repeatRule": "FREQ=WEEKLY;BYDAY=TU",
  "suppressAlerts": true,
  "reason": "Weekly infra maintenance"
}

​
Next steps

Maintenance windows

Schedule planned downtime and configure recurring windows.

Notification policies

Configure the policies that suppression bypasses.

Alerting overview

Understand the full two-layer alerting model.