Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update metric-alert-config.mdx #11760

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions docs/product/alerts/create-alerts/metric-alert-config.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -132,11 +132,11 @@ Change alerts, or alerts that use a percent change threshold, are useful when yo
<Include name="feature-available-for-plan-trial-business.mdx" />
<Include name="feature-available-for-user-group-early-adopter.mdx" />

Anomaly alerts can be used when you don't know what threshold to set, but you know you want to be alerted when something is far outside the bounds of normalcy. Sentry will look at the historical data for the given metric and determine if the current data is anomalous. You have three options for the responsiveness of the alert: low, medium, and high. Low responsiveness means the alert will fire less frequently with each instance being higher signal. High responsiveness will capture more instances of the alert, which creates more coverage with a greater likelihood for false positives. Our recommendation is to start with our default (medium), and iterate based on the results you see.
Another setting is to set the direction of the alert: above and/or below the expected bounds. This setting can help increase the signal of your alert rule.
Anomaly alerts automatically detect trends outside expected values. They can be especially helpful for spiky or seasonal data that are too noisy for static or percentage based thresholds. Sentry will look at historical data for the given metric and determine if the current data is anomalous. Certain metrics, like Apdex, are currently not supported for anomaly alerts.

Critical and Resolved thresholds will be controlled by Sentry rather than the user. When no more anomalies are detected, the alert will resolve. Anomaly alerts are not available for all metric alert types.
There are three options for alert responsiveness: low, medium, and high. If you choose low responsiveness, then your alert will fire less frequently but with higher confidence. If you choose high responsiveness, then your alert will fire more frequently with a greater chance of false positives. Our recommendation is to start with medium responsiveness, our default, and adjust the responsiveness based on the results you see.

Another setting is to set the direction of the alert: above and/or below the expected bounds. This setting can help increase the signal of your alert rule.

![When the dynamic threshold is selected.](./img/dynamic-threshold.png)

Expand All @@ -150,6 +150,12 @@ You can set the status of an alert rule when a threshold is met using the labels

You must set the “Warning” threshold so that it’s triggered before the “Critical” threshold. When Sentry evaluates an alert, the alert’s status is updated to the highest severity trigger that matches. If you don’t set a “Resolved” threshold, the alert automatically resolves when it's no longer breaching the “Critical” or “Warning” conditions. You can also resolve alerts manually.

<Note>

Note: Anomaly alert thresholds are controlled by Sentry and cannot be manually configured.
rachrwang marked this conversation as resolved.
Show resolved Hide resolved

</Note>

### Auto-Resolve

By default, metric alerts are resolved automatically when the specified metric is no longer breaching the “Critical” or “Warning” conditions. However, you can set a different resolution threshold. For example, suppose a normal level of errors for your app is less than 2000/minute, and you want to be alerted when that exceeds 5000/minute. You might want the alert to resolve only if the level of errors goes back below 2000/minute, not 5000/minute. By setting the "Resolved" threshold this way, if the error level comes back down to only 4000/minute, which you’d consider problematic even though it’s below your alert threshold, the alert won't resolve.
Expand Down
Loading