Alert Rule triggers unexpectedly
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 21h 23m
- Merged PRs (30d)
- 607
Description
Environment
SaaS (https://sentry.io/)
Steps to Reproduce
The alert rule in question (see the link in Linear) is scoped to the production environment and is configured to trigger when any of the following occur: a new issue is created, an issue regresses (resolved → unresolved), an issue escalates, or it receives more than one event in an hour. It's also filtered to events with a level of warning or higher.
Around the time the alert fired, the issue had these events:
Jul 15, 2026, 12:01:21 AM UTC - staging
Jul 15, 2026, 12:00:46 AM UTC - production
Jul 14, 2026, 12:01:19 AM UTC - staging
Jul 14, 2026, 12:00:40 AM UTC - production
The most recent activity on the issue was 4 months ago:
Marked as Ongoing - automatically by Sentry after 7 days (4 months ago)
Priority updated to medium by Sentry after the issue was marked ongoing (4 months ago)
The rule's Last Triggered timestamp is Jul 15, 2026, 12:01 AM UTC
Expected Result
The rule should not fire. Since it's scoped to the production environment, only production events should be evaluated. With a single production event in the relevant hour, none of the configured WHEN conditions are met: no new issue, no resolved → unresolved transition, no escalation, and no more than one production event within the hour
Actual Result
Rule fired at Jul 15, 2026 12:01 AM UTC
Product Area
Alerts
Link
No response
DSN
No response
Version
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the Alerts alert-rule evaluation for environment-scoped rules and reproduce the reported sequence of staging and production events. Trace how the production filter and the “more than one event in an hour” condition evaluate the events, then verify that the rule does not trigger for this sequence and that the existing alert behavior remains covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- observability-sre
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100