Document empty-baseline limitation for percent-change issue alerts
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Quiet
- Domain
- documentation
Research direction
Open the linked Issue Alert Configuration page and locate the Change Alerts section. Add a concise caveat covering the same historical time-window slice, the zero-event limitation, and a count-based trigger recommendation for rare issues; then verify the documentation page renders correctly.
Written by the indexing model from the issue text.
Description
Which part? Which one?
Alerts → Issue Alert Configuration → Change Alerts
Description
The Issue Alert Configuration page describes percent-change triggers (e.g., "Number of events in an issue is X% higher in {time} compared to {time} ago") but does not document a key limitation: the comparison is against the exact same time-window slice in the past for that specific issue (not a weekly/daily total or average). When that historical slice contains 0 events, the percent calculation cannot be computed and the rule will not fire, even on a large current spike.
This is particularly impactful for low-frequency issues (a few events per day or less), where the historical comparison slice is statistically very likely to be empty. Customers configure these rules expecting them to catch spikes on rare issues and are surprised when they don't.
Notably, the page already documents the analogous 50-session minimum floor for the Percent-Based Alerts (sessions) section just below, but no equivalent caveat exists for the event/user count percent-change triggers.
Suggested Solution
In the "Change Alerts" section, add a short caveat noting:
- The comparison is the same time-window slice in the past for that specific issue (not an aggregate average).
- If the historical slice contains 0 events, the rule cannot fire regardless of current volume.
- For rare/low-volume issues, recommend pairing or replacing with a count-based trigger (e.g., "the issue is seen more than X times in {time}").
- Dominant language
- MDX
- Stars
- 446
- Forks
- 1.7k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 312
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.
More from getsentry/sentry-docs
-
Docs Platform: Android SDKs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
getsentry/sentry-docs#19438 · 1 comment ·
-
Docs Platform: Python SDKs
Difficulty 1/5 Under an hour Newbie friendliness 92/100
getsentry/sentry-docs#19432 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
getsentry/sentry-docs#19347 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
getsentry/sentry-docs#19182 · 1 comment ·
-
Docs Good First Issue Platform: PHP SDKs
Difficulty 1/5 Under an hour Newbie friendliness 90/100
getsentry/sentry-docs#19177 · 2 comments ·
All issues in getsentry/sentry-docs
Similar issues
-
documentation help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·