> ## Documentation Index
> Fetch the complete documentation index at: https://pulse-41cf5b0d.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Configure Alert Rules in PulseGuard
> Alert rules define when PulseGuard fires notifications. Set thresholds, cooldowns, and route alerts to one or more notification channels.
Alert rules are the bridge between a monitor's raw check results and the people who need to act on them. Each rule is attached to a specific monitor and tells PulseGuard exactly when to fire — how many consecutive failures must occur, which conditions to match, and which notification channels to send to. Without at least one enabled alert rule, a monitor runs silently.
## What Alert Rules Are
An alert rule is a threshold-based policy attached to a monitor. When a monitor's check results satisfy the rule's conditions, PulseGuard dispatches notifications to every channel configured on that rule. You can attach multiple rules to a single monitor — for example, one rule that pages your on-call channel immediately on any failure, and a second rule that emails a reporting list only on recovery.
Rules evaluate after the underlying check has already passed PulseGuard's multi-vector verification layer. This means by the time a rule sees a failure, the platform has already confirmed the issue from multiple geographic vantage points.
PulseGuard runs a **double-check protocol** before declaring a monitor DOWN: every failure is automatically re-verified from alternate edge regions before a status change is recorded. The `alertThreshold` you configure on an alert rule is a separate, additional layer — it controls how many confirmed DOWN results must accumulate before a notification fires.
## Key Fields
The number of **consecutive confirmed failures** that must occur before the rule fires. Defaults to `1`, meaning the first confirmed failure triggers a notification. Raise this value to reduce noise for monitors that experience brief, acceptable blips.
One or more destinations where alerts are sent — Email, Slack, Discord, Webhook, Telegram, or SMS. A single rule can fan out to multiple channels simultaneously.
What condition activates the rule: `STATUS_CHANGE` (UP↔DOWN transitions), `LATENCY` (response time exceeds a threshold), or `SSL_EXPIRY` (certificate nearing expiration).
Optionally narrow a `STATUS_CHANGE` rule to fire only on `DOWN` or only on `UP`. Leave blank to match both directions (useful for combined downtime + recovery alerts).
## Flapping Detection
Monitors that oscillate rapidly between UP and DOWN — often caused by flaky network paths or unstable backend restarts — generate a disproportionate number of alerts without representing genuine, actionable outages. PulseGuard suppresses this noise automatically.
When a monitor goes DOWN and then recovers within a short window, PulseGuard detects the instability and **re-opens the existing incident** rather than creating a new one, appending a "Flapping detected" audit entry to the incident timeline. This keeps your alert history clean and prevents on-call channels from flooding during chaotic recovery events.
## Rate Limiting and Alert Storms
Even outside flapping scenarios, repeated failures on a monitor can generate more notifications than your team can usefully consume. PulseGuard's notification pipeline enforces rate-limiting at the delivery layer, preventing the same alert from hammering a channel repeatedly within a short window. Notifications are deduplicated and delivered in order, giving you a reliable stream rather than a burst of duplicate messages.
## Recovery Alerts
When a monitor transitions from DOWN back to UP, PulseGuard can notify the same channels that received the downtime alert. To receive recovery notifications, configure your alert rule's target status to match `UP`, or leave the target status blank so the rule fires on any status transition.
Recovery notifications include the total **downtime duration** — calculated as the elapsed time between the last recorded DOWN event and the recovery timestamp — so your team has immediate context without digging through logs.
## How to Create an Alert Rule
Navigate to **Dashboard → Monitors** and select the monitor you want to configure. Click the **Alert Rules** tab on the monitor detail page.
Click **Add Alert Rule**. Give the rule a descriptive name (for example, "Critical — Page On-Call") and select a trigger type: **Status Change**, **Latency**, or **SSL Expiry**.
Enter a value for **Alert Threshold** — the number of consecutive confirmed failures required before the rule fires. The default is `1`. For production-critical monitors you likely want to keep this at `1`; for lower-priority monitors consider `2` or `3` to absorb transient blips.
For **Status Change** rules, optionally pin the rule to a specific target status (`DOWN` or `UP`). For **Latency** rules, set the threshold in milliseconds and choose a comparison operator (`GT` for "greater than" or `LT` for "less than"). For **SSL Expiry** rules, set the number of days remaining that should trigger the alert.
Select one or more notification channels from the dropdown. If you have not created any channels yet, click **New Channel** to configure one inline. See [Notification Channels](/alerting/notification-channels) for setup instructions for each channel type.
Toggle the rule to **Enabled** and click **Save**. The rule takes effect on the next check cycle — typically within one minute.
## Editing and Disabling Rules
You can edit any alert rule at any time without affecting monitor operation. Disabling a rule stops notifications from firing but preserves all configuration, making it easy to mute a noisy rule during a maintenance window and re-enable it afterwards.
During planned maintenance, disable alert rules rather than pausing the monitor itself. This way PulseGuard continues recording check results and uptime data, but your team is not paged for expected downtime. You can also use **Maintenance Windows** on the monitor to handle this automatically on a recurring schedule.
Deleting an alert rule is permanent. If you only need to silence a rule temporarily, disable it instead of deleting it.