getsentry / getsentry/sentry

Minimum-baseline floor for percent-change issue alert conditions

Open
#114,120 7 comments 0 reactions 0 assignees View on GitHub
Alerts Bug GitHub Team: alerts-create-issues GitHub Team: alerts-notifications Product Area: Alerts Quality Sprint Waiting for: Product Owner
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
21h 10m
Merged PRs (30d)
635

Description

Issue alert rules using "Number of events/users in an issue is X% higher in {interval} compared to {interval} ago" cannot fire when the historical comparison window is empty for that issue. Percent change against a zero baseline is mathematically undefined and currently treated as 0%, so no positive threshold can be crossed, regardless of how large the current spike is.

This makes percent-change rules unreliable for the very use case they're often configured for: catching unusual spikes on rare/low-frequency issues. A customer with an issue averaging a few events per day is statistically unlikely to have any events in the matching historical comparison window, so a real spike (e.g., 16x the baseline rate) silently fails to trigger.

The "% of sessions" condition already has a 50-session minimum floor that handles its analogous edge case. There is no equivalent for event-count or user-count percent-change conditions.

Solution Brainstorm:
Add a minimum-baseline behavior for percent-change event/user-count conditions. Possible approaches (open to direction from the team):

A configurable minimum baseline floor (e.g., the rule fires when the current count exceeds a minimum count if the baseline is below a threshold).
A sparse-baseline fallback: when the comparison window is empty/sparse, evaluate against a wider window (e.g., daily or weekly aggregate) instead of the exact time-slice.
A hybrid "percent OR count" trigger so users don't have to configure two rules to cover sparse vs. dense issues.
At minimum: a UI warning at rule creation when a percent-change condition is configured against an issue context with low historical volume.

Contributor guide

Open the contributing guide

Research direction

Start by tracing the percent-change event-count and user-count alert conditions, then compare them with the existing 50-session minimum floor for "% of sessions." Clarify with the team whether the intended behavior is a configurable floor, sparse-baseline fallback, hybrid trigger, or UI warning, and define tests that demonstrate a positive alert for an empty or sparse historical window.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.