---
title: "Managing alert incidents"
slug: "managing-alert-incidents-in-tenant-manager"
updated: 2026-11-02T06:53:54Z
published: 2026-11-02T06:53:54Z
canonical: "docs.turbo360.com/managing-alert-incidents-in-tenant-manager"
---

> ## 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 alert incidents

## Overview

**Alert history** lists the incidents that one alert has raised for a tenant, newest first. From it you can filter incidents, acknowledge, close, or reopen them, open the details of an incident, see who changed it, check who was notified, and download the affected records.

An incident is the record of one occurrence of a problem, such as a disabled account that still holds a paid license. For how incidents are raised and escalated, see [Alerts and incident escalation](https://docs.turbo360.com/docs/alerts-and-incident-escalation).

### Business value

Incidents give you a single place to see what an alert found, who is dealing with it, and whether anyone was told. Acknowledging an incident stops it from being sent again while you work on it, and every status change is recorded with who made it and why.

## Prerequisites

Alert history opens for any alert. If the alert is not set up or is disabled, the list tells you so. To set up and switch on an alert, see [Alert types and thresholds](https://docs.turbo360.com/docs/alert-types-and-thresholds-in-tenant-manager).

### Required permissions

You need **Read** on Alerts to view alert history. You need **Manage** on Alerts to acknowledge, close, or reopen an incident. For details, see [Roles and permissions in Tenant Manager](https://docs.turbo360.com/docs/tenant-manager-roles-and-permissions).

| Role | Access |
| --- | --- |
| Owner, Contributor | View history, and acknowledge, close, and reopen incidents. |
| Reader | View history, incident details, user actions, and notification details. |
| Custom role | Whatever the role's **Read** and **Manage** switches for Alerts allow. |

## How it works

Select the tenant in the tree view, expand **License management**, and select **Alerts**. Open the actions menu (⋮) on an alert and select **Alert history**. A link in an alert notification opens the same dialog, and then the details of the incident the notification is about.

### The incident list

The dialog is titled "Alert history" followed by the alert's name. It shows these columns.

| Column | What it shows |
| --- | --- |
| Status | **Open**, **Acknowledged**, or **Closed**. Select it to open the incident details. |
| Issues | A one-line summary of what the check found, for example "17 disabled users still hold a paid license". |
| Alerted at | When the incident was raised, in your browser's time zone. |
| File | A **Download** link for the records file, or "Not stored". |
| Actions | The actions menu for the row. |

The list shows 25 incidents per page. Alert history lists the newest 200 incidents for each alert, and the filters work on those.

The incident details show the status, when the incident was alerted and last updated, the trigger, the severity, the escalation level, a summary, and the issues found, with a **Download issues (.xlsx)** link.

If the alert is not set up, or is disabled, the list says so and tells you to enable the alert. If the alert is on but has raised nothing, the list says that the alert's trigger has not been reached, and shows the trigger.

### Statuses

An incident is **Open** when it is raised. **Acknowledged** means someone has it in hand, so it is not escalated or sent again until it is reopened. It stays acknowledged until someone closes it. **Closed** means it is finished. If the condition is still met when a person closes it, the next check raises a new incident.

Tenant Manager never closes an incident for you. If a later check finds that the condition is no longer met, open incidents stay open and stop escalating, and the log notes that the condition is no longer met. Acknowledge or close them once the problem is dealt with. Acknowledging an incident does not stop the next due check from raising a new one.

## Steps

The steps below cover the common tasks on an incident. You start in **Alert history** for the alert, as described in How it works.

### Filter incidents

This procedure narrows the list to the incidents you want to review.

1. Open **Incident status** and tick **Open**, **Acknowledged**, or **Closed**. If you tick no status, incidents of every status are shown. Select **Clear** to remove the filter.
2. Open **Date** and select **24 hours**, **7 days**, or **30 days**. To choose your own dates, select **Select custom date**, pick **From** and **To**, and select **Apply**.
3. To start again, select **Reset filters to default**.

If nothing matches, the list shows "No results found" and suggests that you change the filters.

### Acknowledge, close, or reopen incidents

This procedure changes the status of one or more incidents. You need **Manage** on Alerts.

1. For one incident, open its actions menu and select **Acknowledge**, **Close**, or **Reopen**. The menu offers only the statuses the incident is not already in.
2. For several incidents, tick them, select **Actions** at the top of the list, and choose the status. If every selected incident is already in that status, the menu tells you.
3. Read the confirmation. It describes what happens next. For example, acknowledging says the incident is not sent again until it is reopened. Reopening resumes the incident's escalation from the step it reached; if the policy had already finished, nothing more is sent for that incident.
4. Enter a **Comment (optional)**, such as a reason or a ticket reference.
5. Select **Continue**.

A message confirms the change, and the comment is stored with the status change.

### View the incident details

This procedure shows what the check found and how it was escalated.

1. Select the status chip, or the text in the **Issues** column.
2. Read the details. Select **View notification details** beside the escalation level to see who was told.
3. Select **Download issues (.xlsx)** to get the affected records.

### View user actions

This procedure shows who changed the status of an incident, and why.

1. Open the incident's actions menu and select **View user actions**.
2. Read the entries. Each one reads "Status changed from ... to ..." with the person's sign-in name, the time, and the comment if there is one. Notes from Tenant Manager, such as "Condition no longer met", also appear.

If nobody has changed the incident, the dialog says so.

### View notification details

This procedure shows who an incident was sent to, and whether each send worked.

1. Open the incident's actions menu and select **View notification details**.
2. Read the list of sends. Each one names the escalation level, and the iteration when a policy repeats.
3. To see every level at once, turn on **View details of all levels**.
4. If a channel shows a failure icon, select it to open **Failure reason**.

### Download the records file

This procedure downloads an Excel file of the records an incident found, such as the disabled accounts.

1. In the **File** column, select **Download**, or select **Download issues (.xlsx)** in the incident details.

For License seat shortage and License expiry the file has one sheet per section; other alerts have one sheet. A **Download records** button also appears in notifications when **Download records from notifications** is on for the alert. The name is the alert name, "issues", and the UTC date and time. Download links in notifications work for 7 days. If a link has expired, download the file from **Alert history** instead.

## Permission behavior

What you can do in **Alert history** depends on your role.

- With **Manage** on Alerts, **Actions** and the row status items are available.
- Without **Manage**, **Actions** and the status items are disabled. Hover over them to see "You are not authorized to perform this operation".
- **View user actions** and **View notification details** stay available to everyone who can read alerts.

## Example scenario

Rosa Alvarez is on the service desk at Margie's Travel. A notification tells her that the client secret of the Margie's Travel tenant is about to expire. She opens **Alert history** from the link and sees one **Open** incident. The **File** column shows "Not stored", because the Client secret expiry alert keeps no records file, so she reads the summary in the incident details instead.

Rosa asks the Microsoft 365 admin to create a new client secret. While she waits, she selects **Acknowledge**, enters the ticket number in **Comment (optional)**, and selects **Continue**. The incident is not sent to the next escalation level. After the admin shares the secret, Rosa saves it on the tenant. Once the alert no longer finds a problem, Rosa closes the incident herself and adds the ticket number as the comment.

## Limitations

- Alert history shows the newest 200 incidents for an alert. Filters work on those only.
- Each due check that finds the condition raises its own incident, so several incidents can be open for one alert at the same time.
- Client secret expiry has no records file.
- The records file is not attached to the notification email. It is a link.

## Troubleshooting

1. **The File column shows "Not stored".** Cause: the alert is Client secret expiry, which keeps no file, or no records were found, or file storage was not available when the incident was raised. Fix: use the incident details for the summary. For other alert types, check your storage configuration with your administrator.
2. **Acknowledge, Close, or Reopen is disabled with "Every selected incident is already ...".** Cause: every ticked incident is already in that status. Fix: tick other incidents, or choose a different status.
3. **An incident was reopened but nothing was sent.** Cause: the alert is disabled, or the escalation policy had already finished. Fix: switch the alert on, and check the repeat setting of the policy. See [Managing escalation policies](https://docs.turbo360.com/docs/managing-escalation-policies-in-tenant-manager).
4. **An incident exists but nobody received a notification.** Cause: the alert has no channel and no recipient, outbound email is not configured, or a channel was deleted. Fix: open **View notification details** and **Failure reason**, and then configure the delivery. See [Alert types and thresholds](https://docs.turbo360.com/docs/alert-types-and-thresholds-in-tenant-manager).
5. **The list says the alert is not set up or is disabled.** Cause: the alert has not been configured on this tenant, or it is switched off. Fix: close the dialog, configure the alert, and switch it on.

## FAQs

1. **What is the difference between Acknowledge and Close?** Acknowledge says someone has the incident in hand. It stops escalating and is not sent again until it is reopened. Close ends the incident, and if the condition is still met, the next check raises a new one.
2. **Why do I see several open incidents for one alert?** Each due check that finds the condition raises its own incident. Acknowledge or close them once the problem is dealt with. Incidents are not closed automatically, even when the condition clears.
3. **Why does the time in Alert history differ from the alert's schedule?** Alert history shows times in your browser's time zone. The alert's schedule uses your account's time zone.

## Related articles

- [Alert types and thresholds](https://docs.turbo360.com/docs/alert-types-and-thresholds-in-tenant-manager)
- [Managing escalation policies](https://docs.turbo360.com/docs/managing-escalation-policies-in-tenant-manager)
- [Notification emails](https://docs.turbo360.com/docs/notification-emails-in-tenant-manager)
- [Alerts and incident escalation](https://docs.turbo360.com/docs/alerts-and-incident-escalation)
- [Roles and permissions in Tenant Manager](https://docs.turbo360.com/docs/tenant-manager-roles-and-permissions)