---
title: "Managing monitoring incidents"
slug: "managing-monitoring-incidents"
updated: 2026-10-29T11:13:36Z
published: 2026-10-29T11:13:36Z
canonical: "docs.turbo360.com/managing-monitoring-incidents"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.turbo360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing monitoring incidents

## Overview

The Incidents sub-tab in the Monitoring tab consolidates all cost alerts triggered across Group budget monitoring, Anomaly detection, and Custom monitors into a single view. From here you can review, filter, acknowledge, close, and reopen incidents, inspect notification delivery details, and audit the actions taken on each alert.

### Business value

A unified incident view means your team spends less time hunting across individual monitor configurations to understand what fired and when. Clear incident states and bulk actions keep cost alert backlogs manageable, and per-incident notification and user-action history gives you the audit trail needed to close the loop on every cost event.

## Prerequisites

At least one monitoring feature must be active on the cost management group before incidents appear: Group budget monitoring, Anomaly detection, or a Custom monitor. No separate setup is required to access the Incidents sub-tab itself.

### Required permissions

Incident access follows the permissions under **Specify monitoring tab permissions** for each source: **Group budget**, **Anomaly detection**, and **Custom monitors**. The **Monitoring** switch under **Specify feature permissions** must be set to **Enable**. **Manage** requires **Read** on the same permission.

| Role | Permission level | Access |
| --- | --- | --- |
| Account owner, Owner, Contributor | - | Full access: view, filter, and manage all incidents |
| Custom role | Group budget: Manage or Custom monitors: Manage | Can view incidents from that source and perform all state actions on them |
| Custom role | Group budget: Read, Anomaly detection: Read, or Custom monitors: Read | Can view incidents and notification details from that source; cannot change incident state |

Permissions apply per source:

- The source tabs **Anomalies**, **Group budget**, and **Custom monitors** appear only for sources the user has **Read** on. Incidents from other sources are not shown.
- Changing an incident's status requires **Manage** on its source. Anomaly incidents are view-only, so **Anomaly detection: Manage** does not add status actions.
- The **Monitoring** tab appears only when the user has **Read** on at least one of **Group budget**, **Anomaly detection**, **Custom monitors**, or **Budget planner**. **Overview**, **Incidents**, and **Change history** have no permission of their own and appear whenever at least one of those four is readable.
- On **Overview**, tiles, the incident feed, and the calendar show only readable sources. **Close all open** counts and closes only incidents from sources the user has **Manage** on.

## How it works

When a cost alert triggers, Cost Analyzer logs it as an incident and assigns it an Open state. Incidents persist until a team member acknowledges or closes them. Each incident carries the source context from its monitor type (Group budget, Anomaly, or Custom monitors), the triggering condition, and the alert timestamp.

Incidents move through a defined lifecycle:

- **Open:** the alert has fired and no action has been taken.
- **Acknowledge:** a team member has noted the incident and is investigating.
- **Closed:** the incident is resolved and no longer requires attention.
- **Reopened:** a previously closed incident has been re-flagged as still relevant.

Incident state transitions are logged as user actions. Every state change records who made it, when, and what the resulting state became. Notification delivery for each incident is tracked separately, showing per-channel delivery results at the time the alert fired.

### Incident categories

The Incidents sub-tab presents incidents across three source categories, each accessible via a filter tab at the top of the list:

- **Anomalies:** incidents generated by Anomaly detection when a statistically significant cost change is detected.
- **Group budget:** incidents generated when cost management group spend crosses a configured budget threshold or percentage threshold.
- **Custom monitors:** incidents generated by Custom monitor rule evaluations.

The **All** tab shows every incident from the sources you can read. Each tab displays a count of incidents for quick triage.

### Filtering and date range

Incidents can be filtered by status (All, Open, Closed) using the Status filter, and by time window using the date range selector. The date range selector supports Last 7 days, Last 30 days, Last 3 months, Last 6 months, and a custom date range. The default view shows the last 30 days.

## Steps

Use the following steps to view, filter, and manage monitoring incidents. Navigate to the desired cost management group, open the **Monitoring** tab, and select the **Incidents** sub-tab to get started. To change an incident's status, select the **Group budget** or **Custom monitors** source tab. The checkboxes, the status options in the context menu, and the **Actions** dropdown appear only on those tabs, and only if you have **Manage** on that source.

### View and filter incidents

Reviewing the incident list lets you triage active cost alerts by source, status, and time window so you can prioritise which to investigate first.

1. On the **Incidents** sub-tab, select the source tab: **All**, **Anomalies**, **Group budget**, or **Custom monitors**.
2. Use the **Status** filter to narrow by incident state: All, Open, or Closed.
3. Use the date range selector to set the time window for incidents displayed.

### Acknowledge an incident

Acknowledging an incident marks it as under investigation, signalling to your team that someone is actively looking into the cost alert.

**Individually:**

1. On the **Incidents** sub-tab, click the **⋯** context menu next to the incident.
2. Select **Acknowledge**.

**In bulk:**

1. Select the checkbox next to one or more incidents.
2. Click the **Actions** dropdown that appears.
3. Select **Acknowledge**.

### Close an incident

Closing an incident marks it as resolved. Use this when the cost event has been investigated and no further action is required.

**Individually:**

1. On the **Incidents** sub-tab, click the **⋯** context menu next to the incident.
2. Select **Close**.

**In bulk:**

1. Select the checkbox next to one or more incidents.
2. Click the **Actions** dropdown.
3. Select **Close**.

### Reopen an incident

Reopening an incident returns it to an active state. Use this when a previously closed incident turns out to still be relevant or unresolved.

**Individually:**

1. On the **Incidents** sub-tab, click the **⋯** context menu next to the incident.
2. Select **Reopen**.

**In bulk:**

1. Select the checkbox next to one or more incidents.
2. Click the **Actions** dropdown.
3. Select **Reopen**.

### View alert details

Viewing alert details opens the full incident record, showing the triggering condition, the cost values at alert time, and the monitor configuration that produced it.

1. On the **Incidents** sub-tab, click the **⋯** context menu next to the incident.
2. Select **View alert details**.

### View user actions

Viewing user actions shows a complete audit log of every state change made on the incident, including who made it and when.

1. On the **Incidents** sub-tab, click the **⋯** context menu next to the incident.
2. Select **View user actions**.

### View notification details

Viewing notification details shows the per-channel delivery record for the alert, including whether each configured channel received the notification and the reason for any delivery failure.

1. On the **Incidents** sub-tab, click the **⋯** context menu next to the incident.
2. Select **View notification details**.

## Troubleshooting

1. **Incidents are not appearing even though a monitor is configured and active** Cause: The monitor may not have triggered yet within the selected date range, the date range filter is excluding the relevant period, or the role does not have **Read** on the source of the incident. Fix: Expand the date range to Last 30 days or Last 3 months and switch the Status filter to All. If the monitor is new, allow at least one evaluation cycle to complete before expecting incidents to appear. If the source tab is missing, ask an administrator to turn on **Read** for that source under **Specify monitoring tab permissions**.
2. **An incident shows as Open but notifications were never received** Cause: The escalation policy or notification channel may be misconfigured, for example, an invalid webhook URL, expired credentials, or an incorrect email recipient. Fix: Click the **⋯** context menu on the incident and select **View notification details** to see the channel-level delivery result and the reason for any failure. Correct the channel configuration in [Managing notification channels](https://docs.turbo360.com/docs/managing-notification-channels) and trigger a test if available.
3. **Bulk Actions dropdown is not visible after selecting incidents** Cause: The Actions dropdown appears only after at least one incident checkbox is selected. Checkboxes appear only on the **Group budget** and **Custom monitors** tabs, and only for users with **Manage** on that source. They do not appear on the **All** or **Anomalies** tab. Fix: Select the **Group budget** or **Custom monitors** tab, and confirm your role has **Manage** on that source. Then select at least one incident using its checkbox. The Actions dropdown appears in the toolbar above the list with the available state transitions for the selected incidents.
4. **Reopen is greyed out on an incident** Cause: Reopen is only available on incidents in a Closed state. Open and Acknowledged incidents cannot be reopened. Fix: Confirm the incident is in a Closed state before attempting to reopen it. Switch the Status filter to Closed to locate the incident if it is not visible in the current view.
5. **User actions log shows no entries for an incident** Cause: No state changes have been made on the incident since it was created. An incident that has remained Open since triggering will have no user action entries. Fix: This is expected behaviour for a newly triggered, untouched incident. User actions are logged only when a team member explicitly changes the incident state.

## FAQs

1. **Do incidents across all monitor types appear in the same Incidents sub-tab?** Yes. The Incidents sub-tab consolidates incidents from Group budget monitoring, Anomaly detection, and Custom monitors into one view. Use the source filter tabs (Anomalies, Group budget, Custom monitors) to view incidents from a specific monitor type. You see only the sources your role has **Read** on.
2. **What happens to an incident when I close it?** Closing an incident removes it from the Open count and marks it as resolved in the audit log. The incident remains visible in the Incidents list when the Status filter is set to All or Closed. It can be reopened at any time if the issue resurfaces.
3. **Can I bulk-manage incidents across different monitor types?** No. Status actions are available only when a single source tab, **Group budget** or **Custom monitors**, is selected, and your role must have **Manage** on that source. Select incidents on that tab and use the Actions dropdown to acknowledge, close, or reopen them together. Anomaly incidents are view-only.

## Related articles

- [Custom monitoring](https://docs.turbo360.com/docs/custom-monitoring)
- [Group budget monitoring](https://docs.turbo360.com/docs/group-budget-monitoring)
- [Automatic anomaly detection](https://docs.turbo360.com/docs/automatic-anomaly-detection)
- [Managing escalation policies](https://docs.turbo360.com/docs/managing-escalation-policies-in-cost-analyzer)
- [Managing notification channels](https://docs.turbo360.com/docs/managing-notification-channels)