Sentry: Feature request: ignore until X occurences per hour

[victormours]

Hi there!

We're currently using Bugsnag, but seriously considering moving to Sentry. Unfortunately, there's a feature in Bugsnag that we miss in Sentry: the possibility to ignore an error until it happens a certain number of times in an hour (or a day).

The typical use case for this is a call to an external API: it may be slightly unreliable, thus making it acceptable to ignore a couple of errors per hour, but if all of a sudden the number of errors per hour increases, we want to know if there is something wrong with the API or if we just deployed code that doesn't call it properly.

This is what it looks like in Bugsnag:

Is this a feature you would consider adding to Sentry?

[dcramer]

@victormours is the expectation that it is always ignored unless it happens above that rate? e.g. is it unignored once? or does it stay in that same state?

[victormours]

I think it would make more sense to unignore the error once, in order to be consistent with the existing behavior of "ignore until X occurrences". Keeping the error in an conditional ignore state would probably be a bit confusing.

If something goes wrong with an external API, we usually want to keep an eye on it, until we manually set a new ignore rule (which can be different from the previous one, e.g. if a fix was deployed to mitigate the issue).
A nice to have would be a "go back to ignore until X occurrences per hour" button for errors that go beyond their threshold, but that's definitely not necessary for a first version.

Does that make sense?

(On a side note: wow, thanks for the quick response ! :D)

[dcramer]

Going to toy with a quick implementation of this over the holiday weekend.

[dcramer]

WIP is feature/expand-ignore. I implemented some of the basics for ignoring by delta counts, but still need to add async rate checks.

[dcramer]

RuleProcessor currently does rate checks, but to avoid mismatched logic I'm just going to extend the task where thats managed to add in the GroupSnooze checks.

[dcramer]

Aside, I might also add "users affected" to the rate capabilities since we already have the data available anyways.

[dcramer]

@victormours will likely finish this up tomorrow once we sort out UI. Aside I'd love to hear why you're moving to Sentry. Feel free to email me directly if you want to share privately ([email protected]).

[victormours]

@dcramer Awesome! My colleague Tim who's been leading the charge on our move to Sentry is going to email you soon to give some more details. :)

[benvinegar]

This is now live on sentry.io (see #5464)

[victormours]

This is awesome. Thank you so much guys!