> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Alert Suppression

> Suppress DevHelm alerts during maintenance windows and via resource group rules

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](/incidents/maintenance-windows) 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](/guides/resource-groups) 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

| Aspect                         | Suppressed | Not suppressed                     |
| ------------------------------ | ---------- | ---------------------------------- |
| Notification policy evaluation | Yes        | —                                  |
| Escalation chain execution     | Yes        | —                                  |
| Channel delivery               | Yes        | —                                  |
| 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

```bash theme={null}
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

```bash theme={null}
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:

```bash theme={null}
devhelm maintenance-windows create \
  --org-wide \
  --start "2026-07-01T14:00:00Z" \
  --end   "2026-07-01T14:30:00Z" \
  --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:

```json theme={null}
{
  "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

<CardGroup cols={2}>
  <Card title="Maintenance windows" icon="calendar" href="/incidents/maintenance-windows">
    Schedule planned downtime and configure recurring windows.
  </Card>

  <Card title="Notification policies" icon="filter" href="/alerting/notification-policies">
    Configure the policies that suppression bypasses.
  </Card>

  <Card title="Alerting overview" icon="bell" href="/alerting/overview">
    Understand the full two-layer alerting model.
  </Card>
</CardGroup>