Skip to main content
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

alertThreshold

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.

Notification Channels

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.

Trigger Type

What condition activates the rule: STATUS_CHANGE (UP↔DOWN transitions), LATENCY (response time exceeds a threshold), or SSL_EXPIRY (certificate nearing expiration).

Target Status

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

1

Open the monitor

Navigate to Dashboard → Monitors and select the monitor you want to configure. Click the Alert Rules tab on the monitor detail page.
2

Add a new rule

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.
3

Set the threshold

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.
4

Configure conditions (optional)

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.
5

Attach notification channels

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 for setup instructions for each channel type.
6

Enable and save

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.