--- title: "Alert configuration" slug: "alert-configuration-in-tenant-manager" updated: 2026-11-02T06:53:54Z published: 2026-11-02T06:53:54Z canonical: "docs.turbo360.com/alert-configuration-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. # Alert configuration ## Overview This article describes how to configure Tenant Manager alerts so the right people hear about a problem in time to act on it. It covers who receives alerts, which alert to set up first, how to choose thresholds, how fresh the data is, and how to respond to an incident. ### Business value An alert is only useful if someone reads it and acts. Good configuration means unused licenses, seat shortages, expiring licenses, and expiring client secrets reach a named person early, without repeat messages burying the important ones. ## How it works Tenant Manager has five alert types: Disabled user with license, Inactive user with license, License seat shortage, License expiry, and Client secret expiry. This section describes the behavior that the key practices rely on. **Each tenant** has its own setting for each alert type. Tenant groups have no **Alerts** page, so you configure alerts on every tenant you want to watch. **Alerts** read the data from the last sync and never read Microsoft 365 when they run. Each tenant syncs every 6 hours, so an alert that runs more often than that finds nothing new. **Last synced** in the tenant page header shows how fresh the data is. For the sync schedule, see [How data sync works](https://docs.turbo360.com/docs/how-data-sync-works). **Incidents** are raised when a check finds the condition. Each due check that finds the condition raises its own incident, even when earlier incidents for the same alert are still open. If a check finds the condition is no longer met, open incidents stay open and stop escalating. Acknowledge or close them once the problem is dealt with. **Escalation policies** decide who is told and when. The first step is notified at once. If nobody acknowledges or closes the incident, Tenant Manager notifies the next step after the delay set on the policy. An acknowledged incident is not escalated. **Recipients** are only the people and channels you set. Tenant Manager does not email the people who hold licenses in your tenants. An alert cannot be switched on until it has a notification channel or a recipient email address. On private hosting there is no recipient field, so tick a channel (use an SMTP channel for email). Until a channel is ticked, the switch is grayed out, and its tooltip reads "Configure this alert first. Choose a notification channel, then enable it." ## Key practices The practices below are in the order to apply them when you set up alerts for a tenant. Each one names where to make the change. ### 1. Set a recipient or a channel before you switch an alert on Every alert is off until it has a destination, and Tenant Manager emails only the recipients and channels you set. On the tenant's **Alerts** page, select **Configure** in the alert's actions menu (⋮), enter a **Recipient email address** or tick a channel, select **Save**, and then use the switch. On private hosting there is no recipient field, so tick a channel (use an SMTP channel for email). Each step without a channel shows a warning icon with "At least one notification channel must be added", and **Save** stays disabled until a step has a channel. If a channel is deleted later, a warning above the grid names the alert that now has nowhere to send. ### 2. Set up the Client secret expiry alert first, on every tenant Once Microsoft rejects a tenant's client secret, the sync stops working. Nothing is updated for that tenant, and the other alerts keep running on the last data read, which no longer reflects the tenant. The alert warns you 30 days before the **Client secret expiration** date by default, so keep that date correct as described in [Managing Microsoft 365 tenants](https://docs.turbo360.com/docs/managing-microsoft-365-tenants). ### 3. Set the License seat shortage lines to match how long it takes you to buy seats The defaults raise a warning at 10 or fewer available seats and an error at 5 or fewer. Count the seats you assign between ordering and receiving a license, and set **Warning** above that number. Change **Warning** and **Error** under **Rule settings** in the **Configure** dialog, in **% of seats** or **Seats**. A changed threshold applies from the next scheduled check. Saving does not start an immediate check. ### 4. Treat every alert result as data from the last sync Alerts never read Microsoft 365 when they run, and each tenant syncs every 6 hours, so an alert that runs more often than that finds nothing new. Check **Last synced** in the tenant page header before you act on an incident. Each due check that finds the condition raises its own incident, so a condition that lasts can leave several incidents open. License expiry and Client secret expiry run once a day at 00:00 and cannot be changed. ### 5. Acknowledge an incident in Alert history, and add a comment Acknowledging tells Tenant Manager that someone has the incident in hand, so it is not escalated or sent again until you reopen it. Closing is different: if the condition is still met, the next check raises a new incident. Open **Alert history** from the alert's actions menu (⋮), open the actions menu on the incident's row, choose **Acknowledge**, and enter a **Comment (optional)** such as a ticket reference. ### 6. Use Notification defaults to give new alerts a recipient On SaaS accounts, a new Tenant Manager alert starts with the recipient from [Notification defaults](https://docs.turbo360.com/docs/notification-defaults), but only when a default is set. Tenant Manager does not fall back to your own email address. Set a default under Settings > Email templates in the **Notification defaults** strip, and change the recipient on any alert that needs a different one. ## Example scenario Callum Reid has just connected the three Silverline Textiles tenants to Tenant Manager. He starts with Client secret expiry. On the **Alerts** page of each tenant, he selects **Configure** in the alert's actions menu (⋮), enters the address of a shared mailbox in **Recipient email address**, selects **Save**, and switches the alert on. Each tenant now warns him 30 days before its client secret expires. Next he sets the License seat shortage lines. Silverline assigns about 20 seats between ordering and receiving a license, so he sets **Warning** to 25 seats and leaves **Error** at 5 under **Rule settings**. When an incident is raised, he checks **Last synced** in the tenant page header, opens **Alert history**, selects **Acknowledge**, and enters the ticket number in **Comment (optional)**. ## Limitations - Alerts read the data from the last sync, and each tenant syncs every 6 hours, so a check cannot find a change that Tenant Manager has not synced yet. - Tenant groups have no **Alerts** page, so you configure alerts on every tenant you want to watch. - License expiry and Client secret expiry run once a day at 00:00 and cannot be changed. - A default recipient from Notification defaults applies on SaaS accounts only, and only when a default is set. ## Related articles - [Alert types and thresholds](https://docs.turbo360.com/docs/alert-types-and-thresholds-in-tenant-manager) - [Managing alert incidents](https://docs.turbo360.com/docs/managing-alert-incidents-in-tenant-manager) - [Managing escalation policies](https://docs.turbo360.com/docs/managing-escalation-policies-in-tenant-manager) - [Alerts and incident escalation](https://docs.turbo360.com/docs/alerts-and-incident-escalation) - [Setting up your first alert](https://docs.turbo360.com/docs/setting-up-your-first-alert-in-tenant-manager) - [Notification defaults](https://docs.turbo360.com/docs/notification-defaults) - [Alert and notification issues](https://docs.turbo360.com/docs/alert-and-notification-issues-in-tenant-manager)