Allow `is:archived` in metric alerts

[JParisFerrer]

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

1. I can create a metric alert with is:archived
   • this seems the most straightforward given it directly ties to the query ability of discover and existing is:unresolved support
   • this enables a workflow where the alert fires, and the triaging individual manually runs the query to identify high volume archived issues
2. P1: I can create an issue alert for incoming events inside an archived issue / I can set an issue alert to include archived issues
   • this would likely involve more work as the filtering mechanism is different
   • this enables a workflow where an alert can directly tell the triaging individual that a certain archived issue is too high volume
   • Moved to Allow creation of Issue alerts that can filter on archived state #102085

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:

• it will constantly show UI telling you that it isn't supported
• it seems to roll back any changes to the alerts, such as thresholds
• it doesn't correctly in the UI tell you the firing status (even if you get firing and resolving emails from the action of the alert)

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/

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-alerts for triage ⏲️

[ceorourke]

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)?

[JParisFerrer]

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