Diagnose: alert rule never fires

TL;DR

A rule set to fire on new issues does not fire on regressed or escalating ones, and vice versa. Check the rule's event triggers against what the issue actually did. The alert's detail page shows run history; an empty run history means the rule never matched, a throttled history means it matched and was suppressed. If a Member created the rule while the org disabled member creation, the rule may exist in a broken state.

When to use

You are seeing this: Open an issue that should have triggered the alert and check it against every filter on the rule: project, environment, issue category, severity, tags. Use this skill when you run into "Diagnose: alert rule never fires".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Step 1: does the issue match the filters?

Open an issue that should have triggered the alert and check it against every filter on the rule: project, environment, issue category, severity, tags. The environment filter is the most common miss: the rule watches production while the issue is tagged prod or has no environment set. One mismatched filter means silence.

Step 2: did the trigger condition actually occur?

A rule set to fire on new issues does not fire on regressed or escalating ones, and vice versa. Check the rule's event triggers against what the issue actually did. Also check throttling: alert throttling suppresses repeat firings by design, so the first event fired and the rest were throttled. The alert's detail page shows run history; an empty run history means the rule never matched, a throttled history means it matched and was suppressed.

Step 3: can the action deliver?

The action depends on an integration (Slack, Jira, webhook, PagerDuty). If the integration was disconnected, its token expired, or the channel was archived, the alert fires into the void. Test the integration independently of the rule.

Step 4: permissions

Alert creation and editing is role-gated. If a Member created the rule while the org disabled member creation, the rule may exist in a broken state. Org-wide alerts (all projects) require Owner or Manager. Confirm the rule's owner role and that the toggle is actually on: rules get saved disabled more often than anyone admits.

Verify

Trigger a test issue matching the filters exactly (same project, same environment string) and watch the alert's run history show the run and the action deliver. Then re-tighten any filter you loosened for testing.

Researched against live Sentry docs 2026-09-26. The alerts page (docs.sentry.io/product/monitors-and-alerts/alerts/) documents: alerts take action when issues match pre-defined rules; creation from Monitors > Alerts with issue sources, event triggers, filters, actions, and throttling; alerts are org-level with role rules (Owners/Managers/Admins/Team Admins always; Members/Contributors only if Let Members Create and Edit Monitors and Alerts is enabled); alerts scoped to all projects restricted to Owners/Managers; and the best-practice guidance on triggers and filters. The releases page (docs.sentry.io/product/releases/) documents environments as a first-class dimension.