Alert Statuses
Updating the Status of an alert has two key benefits:
- Communication: the rest of your team will know that somebody has triaged the issue and if it still pending or not. Filtering just for alerts with no status is an easy way to ensure nothing has fallen through the cracks.
- Reporting: key operational metrics, like Time to Response and Status Update Rate, are only calculated if the status is updated. These metrics are valuable for setting goals and communicating progress to leadership.
Status | Intended purpose | Impacts ML Models? |
---|---|---|
No Status | The default for a newly created alert. | No |
Acknowledged (formerly Investigating) | Someone has acknowledged and is actively investigating if this is a meaningful issue. | No |
Work in progress | It was a meaningful issue that is currently being fixed. | No |
Fixed | The issue was fixed and the data is now back to normal. | Metrics & Custom SQL Monitors only* |
Expected | The detection was a valid anomaly from a statistical standpoint, but was the expected result of something like a pipeline change or planned maintenance. | No |
No action needed | The detection was a valid anomaly from a statistical standpoint, but was not important enough to merit any further action. | No |
False positive | The detection was not a valid statistical anomaly. Sometimes, this can be the result of a data collection issue from Monte Carlo. | No |
*Marking an alert from a Metric or Custom SQL Monitor as Fixed results in the anomaly being removed from the training set for machine learning thresholds. This helps to keep thresholds accurate and sensitive. This workflow will be deprecated by April 2025 and replaced with marking as normal and selecting training data.
Updated 10 days ago