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

# Alerts & Notifications

> Understand how TenantCore surfaces infrastructure issues in the application and sends proactive email notifications.

# Alerts & Notifications

TenantCore uses **Alerts** and **Notifications** for two related but different purposes.

## Alerts

Alerts represent infrastructure conditions that TenantCore has detected and that may require attention.

Examples can include:

* tenant service-health problems
* DNS or authentication changes
* sending-location changes
* licence or permission issues
* reputation warnings
* connection failures

Alerts are visible in the TenantCore application.

The Alerts experience separates current issues from resolved ones so the operator can focus on what still needs action.

## Notifications

Notifications deliver relevant TenantCore events proactively by email.

The notification email defaults to the signed-in user and can be updated in Settings.

TenantCore can use notifications for conditions such as:

* infrastructure warning opened
* infrastructure recovered
* automatic DNS completion
* sending-location change
* reputation warning
* restriction or recovery events

## Alerts vs. Reports

Alerts answer:

> What needs my attention now?

Reports answer:

> What happened over time?

A resolved issue may no longer be an active alert but can still remain part of the historical operational record in Reports.

## Plan behavior

Core alerts and proactive infrastructure notifications are part of TenantCore's safety and visibility model.

Some automation-specific notifications depend on the capability that generated them.

For example, automatic DNS completion is tied to Automatic DNS availability.

## Notification failures

A notification-delivery failure should not change the underlying infrastructure state.

TenantCore treats email delivery as a separate workflow so the system can retry delivery without pretending the original event did not occur.

## Keep notification content actionable

A useful notification should tell the operator:

* what changed
* which tenant/domain/mailbox is affected
* the measured condition where relevant
* what TenantCore did
* what the operator should do next
* how recovery works where applicable

The goal is to reduce the need to open a support ticket simply to understand the state.