To lessen the noise and make issue tracking with our Sentry integration more effective, the default behavior of Sentry’s alert rule settings is to update existing Height tasks during new instances of an alert.

This means instead of creating a new Height task each time a Sentry alert triggers, the Sentry bot will post a message in an existing Height task with a link to the new alert event — making it easier to track all events of the same issue in a single task.

De-duping issue alerts vs. metric alerts

When it comes to de-duping, issue alerts and metric alerts are handled differently. For issue alerts, if the ID of the Sentry issue is already linked to an existing Height task, the alert will be considered a duplicate and an updated message will be posted in the existing task.

For metric alerts, the setting considers the threshold of the alert (Critical, Warning, Resolved) when updating an existing task.

If the alert has not yet gone back into a resolved state, and the issue ID matches one from an existing task, the alert will be considered a duplicate and no new task will be created. However, if a triggered metric alert becomes resolved at any point, the next new alert will not be considered a duplicate and a new task will be created.

Configuring Sentry to create new tasks per alert

Because alert rule settings can be configured per alert, you can set the alert rule to respond differently based on an alert’s severity. For example, you may want critical alerts to always create a new task.

To do this, simply select Create a new task as the rule setting and new Height tasks will be created per Sentry alert.

Any changes to Sentry rule settings are reversible and can be updated and adjusted when needed 😃

Did this answer your question?