Open JParisFerrer opened 1 week ago
Assigning to @getsentry/support for routing ⏲️
Routing to @getsentry/product-owners-alerts for triage ⏲️
Just to confirm, is this because simply removing is:unresolved
isn't granular enough for your use case (you don't want to include resolved issues)?
This is specifically targeting Archived but not Resolved issues. ie, issues that we cannot resolve because they are still emitted from the code, so Sentry would (correctly) reopen them if you attempted to resolve them.
simply removing is:unresolved isn't granular enough
There is no existing alert here, we want an alert to specifically target Archived issues. Our expectation is that vast majority of these would be unresolved (if they were resolved, then there wouldn't also be a need to archive them)
Also, fyi this is associated with a customer case which @yuval-sentry or @irodrigues-git can point you to which should have more information associated to it
It is possible to use the
is:archived
filter in the issue stream and Discover to find issues which have been Archived. that is, issues that stop triggering alerts but continue to be ingested (and consume Sentry quota).It's possible that somebody archives an issue incorrectly -- maybe for the wrong threshold, or for the wrong reason. We'd like to be able to detect when we have high-volume but archived issues so that we can address them. Without the ability to write an alert this seems impossible and depends on manually searching issues periodically.
Expected Behavior
is:archived
Actual Behavior
This seems to be half-supported, in that if you "create alert" from a Discover query that is just
is:archived
, the alert will half work. However:Notes
This is similar to this previous issue (#74063) / this new feature from Feb 2024: https://sentry.io/changelog/removing-archived-issues-from-metric-alerts/