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}").
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: