Feature Request: Filtering issues from multiple releases in alert criteria

[nickaein]

For Alert criteria Sentry currently supports filtering issues from the latest release:

While this is a neat feature, it doesn’t entirely cover some scenarios. For instance, we rollout our releases gradually and there is often multiple “latest” release available online. Naturally, we are interested in monitoring a couple of them, not just the latest one.

It would be nice if the filter is extended so that one can specify N number of latest releases that should be monitored for alert.

[NickMeis]

Hey there,

Thanks for the feedback. We would definitely encourage you to head over to our issues creation page in our sentry repo and create a new feature request.

I personally haven’t tried this, and can’t vouch for it, but I am wondering if some variation of this configuration might work for you?

It’s unfortunately very manual. Whereas being able to specify “N number of latest releases” would certainly require less maintenance.

You might need to play around with release or release.version. You can try entering different tags into the search field on the Issues page to see what values come up in the auto complete suggestions.

[adhiraj]

@nickaein can you elaborate on your release process a bit more? What type of project is it (mobile, server, frontend), how frequently you release, how you use environments, and what type of alert you’re looking to create?

[nickaein]

Hey Adhiraj,

It’s a mobile app which we adhere a fast development-release-feedback loop, so the releases has usually ~10 days interval (~3 releases each month). We are only using “production” environment on Sentry and manage our Beta releases on Google Play Services.

Since it takes some time for the users to adopt to latest release, so we have to monitor multiples releases for any issues. The alert we are creating is as simple as seeing “new issue” more than 1 time in a week. We don’t want to monitor for issues in older releases though (e.g. releases older than months), as they are practically deprecated.

The solution proposed by @NickMeis is ok (and honestly doable) and it may cover our use-cases (since we are developing some automation scripts for our releaes), but it would be really nice if Sentry supported monitoring multiple recent releases, e.g. by date interval or number of releases.

[adhiraj]

Gotcha. Suppose we had the ability to say latest N releases. Which releases would those be? The N biggest version numbers? Do you not have internal/daily builds in there that you’d like to exclude (since you’re using a single environment).

Also you can restrict alerts to issues older/newer than a certain time - would that workaround work?

[nickaein]

Which releases would those be?

I think “issue from N most recent releases” (based on release date/first seen) would suffice in our case. Or even better, an “issues from the releases published in recent X days” filter which we can better reason with.

The N biggest version numbers?

A filter on version number will do the job too, since the buildNumber for android release should always increase. However, its definition can be platform-dependent (e.g. non-Android projects may not have an order-able version number).

Do you not have internal/daily builds in there that you’d like to exclude?

We have “staging” and “production” environments, but we still get many alerts from the users in production environment who are using old app versions and we are not interested in.

Also you can restrict alerts to issues older/newer than a certain time - would that workaround work?

That would be an improvement. However, a significant part of the issues we are receiving and we trying to filter out are "New issue"s from the older versions which have become irrelevant in our development and we have no plan for their maintenance.