Alert Cooldowns and Deduplication

Alert Cooldowns and Deduplication

The cooldown period on an alert rule controls how frequently PulseAPI can fire that rule for the same monitor. This article explains how cooldowns prevent notification spam and how to set an appropriate value.

The Problem Cooldowns Solve

Without a cooldown, a rule could fire on every check. If your monitor checks every 60 seconds and stays down for 2 hours, you'd receive 120 notifications. That's alert fatigue — and alert fatigue makes teams start ignoring notifications, which is dangerous.

The cooldown period says: "once this rule fires for a monitor, don't fire it again for at least N minutes/hours."

How Cooldowns Work

When a rule fires:

  1. An incident is created
  2. Notifications are sent to the assigned channels
  3. A "cooldown timer" starts for that rule + monitor combination

While the timer is active, the rule will not fire again for that monitor — even if every subsequent check fails. The rule resumes normal evaluation once the cooldown expires.

Example:

  • Rule cooldown: 30 minutes
  • Rule fires at 2:00 PM → incident created, notification sent
  • Checks continue to fail at 2:01 PM, 2:02 PM ... 2:29 PM → no additional notifications
  • Rule can fire again at 2:30 PM if the monitor is still failing

Cooldown Does Not Suppress Incident Updates

The cooldown only prevents new incidents from being created and new notifications from being sent. It does not affect:

  • The existing open incident (which stays open)
  • Auto-resolution (when checks pass, the incident resolves regardless of cooldown)
  • Manual acknowledgment or resolution

Recommended Cooldown Values

Priority Recommended Cooldown
Critical 5–15 minutes
High 15–30 minutes
Medium 30–60 minutes
Low 60–120 minutes

Shorter cooldowns mean faster re-notifications if an incident persists unresolved — useful for Critical situations where you want continued pressure to act. Longer cooldowns reduce noise for lower-priority issues.

Cooldown per Rule, per Monitor

Cooldowns are tracked independently per rule + monitor pair. A rule that fires for Monitor A starts a cooldown for Monitor A only — it can still fire for Monitor B if Monitor B meets the condition independently.

Related Articles

Still have questions? Contact support.

    • Related Articles

    • Alert Accuracy Dashboard

      The Alert Accuracy Dashboard tracks your team's false positive rate over time and helps you identify which alert rules are generating noise. It's available on Professional and Team plans. What It Shows The Alert Accuracy Dashboard gives you: ...

    • Creating an Alert Rule

      This article walks you through creating an alert rule in PulseAPI. Alert rules define when PulseAPI creates an incident and sends notifications. Prerequisites: At least one notification channel must exist before you can assign it to a rule. See ...

    • How Alert Rules Work

      An alert rule defines the condition under which PulseAPI creates an incident and sends notifications. This article explains the evaluation flow, the components of a rule, and common configuration patterns. The Evaluation Flow After every check, ...

    • Why Am I Not Receiving Alert Notifications?

      If your monitor goes down but you didn't receive an alert, work through this checklist to find the cause. Most cases have a simple fix. Checklist 1. Does an incident actually exist? Check Incidents in the left sidebar. If no incident was created for ...

    • Setting Rule Priority

      The priority of an alert rule determines the severity of the incidents it creates. This article explains how priority maps to severity and how to choose the right priority for each rule. How Priority Works Every alert rule has a priority: Critical, ...