# Notifications for Confluent Cloud You can manage notifications for account, billing, and service events with the Confluent Cloud Console or with a REST API. Service events are conditions or incidents related to the operation or status of a Confluent Cloud service that triggers a notification. Examples of service events include cluster shrink failures, service outages, upgrades, scaling activities, or other operational statuses that might impact your Apache Kafka® clusters or managed services. ## View notifications The bell icon in the Confluent Cloud Console shows a **Recent notifications** summary of the notifications generated for the resources you are subscribed to. The summary includes counts for **Unread**, **Critical**, **Warning**, and **Informational** notifications. To view your notifications: 1. Sign in to Confluent Cloud. 2. Click the bell icon in the Confluent Cloud Console to open the **Recent notifications** summary popover. 3. Click **View all notifications** to open the **Notifications** page. 4. Click a notification to view its details. ## Configure notifications You can configure notifications in two ways: - **Organization level**: Accessible to organization administrators, or if using role-based access control (RBAC), users with the OrganizationAdmin role. - **Resource level**: Accessible to users with write access to a resource such as a cluster or connector. Organization- and resource-level notifications are accessible to users assigned the [OrganizationAdmin role](../security/access-control/rbac/predefined-rbac-roles.md#cloud-rbac-roles), who can make bulk changes across all notifications. For example, an organization administrator can subscribe once to a ‘failed connector’ notification type at the organization level to be notified if any connector in the organization fails. A resource-level subscription to that same notification type on an individual connector only notifies you when that specific connector fails. Organization administrator users always receive required notifications by email, and can configure more users and channels for a notification. If your organization uses role-based access control (RBAC), notifications are sent to the users directly assigned the [OrganizationAdmin role](../security/access-control/rbac/predefined-rbac-roles.md#cloud-rbac-roles). Users granted the OrganizationAdmin role through [group mapping](../_glossary.md#term-group-mapping) are not sent notifications. All other RBAC roles have read-only access to notifications. Anyone with write-level access to a resource can configure resource-level notifications for that resource. This includes resource managers and administrator-level users. For notifications, you should understand the following terms: - **Notification type**: The type of notification based on the Confluent Cloud event that has occurred. Each notification type defines a condition that must be met. Notification types are categorized as account, billing and licensing, or service, and can be filtered by [severity level](#notification-severity-levels). For example, a Dedicated cluster shrink failure is a warning-level service notification type. - **Integration**: Describes the configured notification channel for sending a notification event: Email, Microsoft Teams, Slack, or a generic webhook. The default integration is email, and notifications are sent to the organization’s administrator or if using RBAC, users that have the [OrganizationAdmin role](../security/access-control/rbac/predefined-rbac-roles.md#cloud-rbac-roles). - **Subscription**: Represents the association of a notification type to an integration channel. A user creates subscriptions for a particular notification type and as a result is notified through the integration channels they have configured for that subscription. You can view the current notification subscriptions and configure additional integrations and subscriptions to those integrations using the Cloud Console or a REST API. For example, you can configure a Slack integration, and then subscribe to this integration for a **Kafka cluster shrink failure** notification type. ## Manage notifications at the organization level You can manage notifications for your organization in the Cloud Console or with the REST API. You must be an organization administrator or have the [OrganizationAdmin role](../security/access-control/rbac/predefined-rbac-roles.md#cloud-rbac-roles) to manage these notifications. ### See a list of subscriptions If you are an organization administrator, you can view your notification integrations and subscriptions in the Cloud Console or by making a GET call to the REST API. ### Cloud Console To see a list of the recent notifications for subscriptions and integrations you currently have configured, click the bell icon in the Cloud Console. This opens the **Recent notifications** panel. ![Bell icon and Recent notifications panel.](images/_monitoring/notifications-recent.png) This summary shows only your most recent notifications. To open the **Notifications** page and view or sort all of your notifications by category—including severity, resource type, environment, and tags—click **View all notifications**. To manage organization notifications, click the gear icon, which opens the **Manage notifications for this organization** drawer. You can also click **Manage organization notifications** on the **Notifications** page. ![Notifications dashboard page.](images/_monitoring/notifications-dashboard-page.png) You can only access the notification management features if you are an organization administrator. Otherwise, access notifications at the resource level for resources you have write access to, as described in the [Resource-level notifications](#ccloud-notifications-resource-level) section. You can filter subscriptions by severity, category, channel, type, and status. ![image](images/_monitoring/manage-notifications-org.png) ### REST API To list all of the subscriptions associated with that subscription, make a GET call to the `subscriptions` endpoint. The request should include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). This retrieves a filtered and paginated list of all subscriptions along with integration details associated with them. For a full list of APIs, see [Confluent Cloud APIs](https://docs.confluent.io/cloud/current/api.html). ```none GET /notifications/v1/subscriptions HTTP/1.1 Host: api.confluent.cloud ``` A successful response is `200 OK` with a JSON payload that contains a subscription list for that organization. Each `resource_name` value is a Confluent Resource Name (CRN), a URI that uniquely identifies the resource. For more information about this format, see [Confluent Resource Names (CRNs)](../security/access-control/hierarchy/confluent-resource-names.md#confluent-resource-names). The example response that follows has been shortened for brevity. ```none HTTP/1.1 200 OK { "api_version": "notifications/v1", "kind": "SubscriptionList", "metadata": { "first": "https://api.confluent.cloud/notifications/v1/subscriptions" }, "data": [ { "notification_type": { "resource_name": "crn://confluent.cloud/notification-type=nt-12JlG", "api_version": "notifications/v1", "id": "nt-l2JlG", "kind": "notification-type", "related": "https://api.confluent.cloud/notifications/v1/notification-types/nt-12JlG" }, "integrations": [ { "resource_name": "crn://confluent.cloud/integration=i-e0KAB", "api_version": "notifications/v1", "id": "i-e0KAB", "kind": "integration", "related": "https://api.confluent.cloud/notifications/v1/integrations/i-e0KAB" } ], "current_state": "ENABLED", "api_version": "notifications/v1", "kind": "Subscription", "id": "s-56R4y", "metadata": { "self": "https://api.confluent.cloud/notifications/v1/subscriptions/s-56R4y", "resource_name": "crn://confluent.cloud/subscription=s-56R4y", "created_at": "2022-08-23T23:02:18.455Z", "updated_at": "2022-08-23T23:02:18.455Z" } }, { "notification_type": { "resource_name": "crn://confluent.cloud/notification-type=nt-DbPQ9", "api_version": "notifications/v1", "id": "nt-DbPQ9", "kind": "notification-type", "related": "https://api.confluent.cloud/notifications/v1/notification-types/nt-DbPQ9" }, "integrations": [ { "resource_name": "crn://confluent.cloud/integration=i-e0KAB", "api_version": "notifications/v1", "id": "i-e0KAB", "kind": "integration", "related": "https://api.confluent.cloud/notifications/v1/integrations/i-e0KAB" }, { "resource_name": "crn://confluent.cloud/integration=i-jYa83", "api_version": "notifications/v1", "id": "i-jYa83", "kind": "integration", "related": "https://api.confluent.cloud/notifications/v1/integrations/i-jYa83" } ], "current_state": "ENABLED", "api_version": "notifications/v1", "kind": "Subscription", "id": "s-rZ9yx", "metadata": { "self": "https://api.confluent.cloud/notifications/v1/subscriptions/s-rZ9yx", "resource_name": "crn://confluent.cloud/subscription=s-rZ9yx", "created_at": "2022-08-23T23:03:19.328Z", "updated_at": "2022-09-15T23:49:00.422Z" } } ] } ``` ### Configure integrations and subscriptions You can configure Slack, Microsoft Teams, or generic webhook integrations for some notification types. You must be an organization administrator or have the [OrganizationAdmin role](../security/access-control/rbac/predefined-rbac-roles.md#cloud-rbac-roles) to configure integrations. Microsoft retired Office 365 connector-based webhooks for Microsoft Teams in May 2026. If you configured a Microsoft Teams integration before then, recreate it using a Workflows-based webhook, as described in the following steps. For more information, see [Retirement of Office 365 connectors within Microsoft Teams](https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/) and [Update connectors URL](https://learn.microsoft.com/en-us/microsoftteams/m365-custom-connectors#update-connectors-url). To configure an integration and subscribe to a notification type for that integration: ### Cloud Console 1. Sign in to Confluent Cloud and click the bell icon. ![Bell icon and Recent notifications panel.](images/_monitoring/notifications-recent.png) 2. Click the gear icon, or click **View all notifications** to open the **Notifications** page. 3. Click **Manage organization notifications** to open the **Manage notifications** panel. 4. Click the edit icon for the notification type you want to configure. ![Confluent Cloud notification edit icon](images/_monitoring/notifications-list-edit-icon.png) 5. You can configure a new integration by entering a URL or recipient. The following image shows how to configure a new Slack integration. ![image](images/_monitoring/edit-notification-panel.png) - **Email** - Click **Add recipients** and enter one or more roles or users to receive notification emails. Email is checked by default for recommended and required notification types, and the OrganizationAdmin role configured by default to receive emails. - **Slack** - To add a new integration, click **add a Slack URL** and enter a **Name** for the integration, such as the channel or team name that receives the notification, and the **Slack URL**. For more information, see [Slack incoming webhooks](https://api.slack.com/messaging/webhooks). - **Microsoft Teams** - To add a new integration, click **add a Microsoft Teams URL** and enter a **Name** for the integration, such as the channel or team name that receives the notification, and the **Microsoft Teams URL**. For more information, see [Microsoft Teams incoming webhooks](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498#:~:text=Select%20More%20options%20next%20to%20the%20channel%20or,needs.%20Each%20template%20has%20a%20different%20authentication%20type.). - **Webhook** - To add a new integration, click **Add Webhook URL** and enter a **Name** for the integration. The webhook receives messages in the following format: ```bash { id: string [required] title: string message: string created_at: string } ``` 6. Click **Verify** for each URL you enter, and Confluent Cloud sends a test message to the URL. After a URL is verified, you can click **Save** to save the integration, and check it to add a subscription using that integration. If the URL cannot be verified, you cannot save your changes. ### REST API To configure a subscription with the REST API, you first create an integration, then retrieve a list of notification types, and specify an integration and notification type to add a subscription. For a full list of APIs, see [Confluent Cloud APIs](https://docs.confluent.io/cloud/current/api.html). 1. To create the integration, send a POST request to the `integrations` endpoint, and include the description of the integration as a JSON payload. The request should include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). The payload should include the name, description, and URL for a [Slack](https://api.slack.com/messaging/webhooks), [Microsoft Teams](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498#:~:text=Select%20More%20options%20next%20to%20the%20channel%20or,needs.%20Each%20template%20has%20a%20different%20authentication%20type.), or generic webhook integration. ```none POST /notifications/v1/integrations HTTP/1.1 Host: api.confluent.cloud { "display_name": "Slack integration", "description": "A Slack channel integration", "target": { "kind": "Slack", "webhook_url": "https://hooks.slack.com/services/T03QJN0HR12/B123QDZTG3W/abczdb" } } ``` A successful response is a `201 Created` message with a JSON payload that resembles the following: ```none HTTP/1.1 201 Created { "api_version": "notifications/v1", "kind": "Integration", "id": "i-a1KrA", "metadata": { "self": "https://api.confluent.cloud/notifications/v1/integrations/i-a1KrA", "resource_name": "crn://confluent.cloud/integration=i-e0KrA", "created_at": "2022-09-15T23:52:20.884Z", "updated_at": "2022-09-15T23:52:20.884Z" }, "display_name": "Slack integration", "description": "A Slack channel integration", "target": { "kind": "Slack", "webhook_url": "https://hooks.slack.com/services/T03QJN0HR12/B123QDZTG3W/abczdb" } } ``` 2. Next, make a GET call to the `notification-types` endpoint to retrieve a list of notifications you can subscribe to. The request should include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). For a full list of APIs, see [Confluent Cloud APIs](https://docs.confluent.io/cloud/current/api.html). ```none GET /notifications/v1/notification-types HTTP/1.1 Host: api.confluent.cloud ``` A successful response looks like the following (returned list shortened for brevity): ```none HTTP/1.1 200 OK { "api_version": "notifications/v1", "kind": "NotificationTypeList", "metadata": { "first": "https://api.confluent.cloud/notifications/v1/notification-types" }, "data": [ { "api_version": "notifications/v1", "kind": "NotificationType", "id": "nt-DbPQ9", "metadata": { "self": "https://api.confluent.cloud/notifications/v1/notification-types/nt-DbPQ9", "resource_name": "crn://confluent.cloud/notification-type=nt-DbPQ9", "created_at": "2022-04-11T13:56:58.817769Z", "updated_at": "2022-04-11T13:56:58.817769Z" }, "display_name": "30 days have elapsed since org was created", "description": "30 days have elapsed since org was created", "category": "BILLING_LICENSING", "subscription_priority": "RECOMMENDED", "is_included_in_plan": true, "severity": "INFO" }, { "api_version": "notifications/v1", "kind": "NotificationType", "id": "nt-abc123", "metadata": { "self": "https://api.confluent.cloud/notifications/v1/notification-types/nt-abc123", "resource_name": "crn://confluent.cloud/notification-type=nt-abc123", "created_at": "2022-04-21T12:15:44.503490Z", "updated_at": "2022-04-21T12:15:44.503490Z" }, "display_name": "Reached 50% of your environment quota", "description": "Confluent Cloud Service Quota usage > 50%.", "category": "SERVICE", "subscription_priority": "OPTIONAL", "is_included_in_plan": true, "severity": "INFO" } ] } ``` 3. Next you create a subscription by sending a POST request to the `subscriptions` endpoint with a JSON payload that denotes the current state of the subscription, identifies the notification type you want to subscribe to, the integration ID for the integration you want to configure, and the environment where it was created. You can only create one subscription per notification type. Omitting `current_state` or attempts to create more than one subscription result in an error. The request should include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). For a full list of APIs, see [Confluent Cloud APIs](https://docs.confluent.io/cloud/current/api.html). ```none POST /notifications/v1/subscriptions HTTP/1.1 { "current_state": "ENABLED", "notification_type": { "resource_name": "crn://confluent.cloud/notification-type=nt-abc123", "api_version": "notifications/v1", "id": "nt-abc123", "kind": "notification-type", "related": "https://api.confluent.cloud/notifications/v1/notification-types/nt-abc123" }, "integrations": [ { "id": "i-e0KrA", "environment": "env-0xovp6" } ] } ``` A successful response resembles the following: ```none 201 ACCEPTED { "notification_type": { "resource_name": "crn://confluent.cloud/notification-type=nt-abc123", "api_version": "notifications/v1", "id": "nt-abc123", "kind": "notification-type", "related": "https://api.confluent.cloud/notifications/v1/notification-types/nt-abc123" }, "integrations": [ { "resource_name": "crn://confluent.cloud/integration=i-e0KrA", "api_version": "notifications/v1", "id": "i-e0KrA", "kind": "integration", "related": "https://api.confluent.cloud/notifications/v1/integrations/i-e0KrA" } ], "current_state": "ENABLED", "api_version": "notifications/v1", "kind": "Subscription", "id": "s-3GRE9", "metadata": { "self": "https://api.confluent.cloud/notifications/v1/subscriptions/s-3GRE9", "resource_name": "crn://confluent.cloud/subscription=s-3GRE9", "created_at": "2022-09-21T18:14:20.952Z", "updated_at": "2022-09-21T18:14:20.952Z" } } ``` ## Manage notifications at the resource level If you are the resource owner, you can view and configure notifications for a resource in the Cloud Console or using the REST API. Resources that support this feature include: - Environments - Clusters - Topics - Connectors In the Cloud Console, if **Manage notifications** does not appear or is grayed out, you do not have write access and cannot manage notifications for that resource. The next few sections provide some examples of using the REST API for resources. For a full list of REST APIs, see [Confluent Cloud APIs](https://docs.confluent.io/cloud/current/api.html). ### Mute notifications You can mute all notifications for a resource. This feature is useful for test or development environments, where notifications are not required or useful. When you mute notifications at the environment level, the mute is cascading, meaning notifications are muted for every resource in the environment. If you mute notifications for a lower-level resource such as a connector, the mute is only applied to that resource. ### Cloud Console To mute notifications for an environment, on the environment overview page, select the **Actions** menu, and click the **Manage notifications** option. ![image](images/_monitoring/environment-actions-manage-notifications.png) When you click **Manage notifications**, a side panel opens where you can mute notifications for that environment. ![image](images/_monitoring/notifications-mute-environment-toggle.png) ### REST API To set whether notifications are muted for a resource using the REST API: - To mute or unmute a resource for the first time, send a POST request to `/notifications/v1/resource-preferences`. - To change the mute setting after it has already been set, send a PATCH request to `/notifications/v1/resource-preferences`. The request must include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). The following example shows how to mute notifications for an environment. ```none POST /notifications/v1/resource-preferences HTTP/1.1 Host: api.confluent.cloud { "resource": "environment=env-abc123", "resource_type": "ENVIRONMENT", "current_state": "DISABLED" } ``` A successful response is `201 Created` with a JSON payload containing the updated environment: ```none HTTP/1.1 201 Created { "api_version": "notifications/v1", "kind": "ResourcePreference", "id": "dlx-abc1234", "metadata": { "self": "https://api.confluent.cloud/notifications/v1/resource-preferences/rp-12345", "resource_name": "crn://confluent.cloud/environment=env-abc123", "created_at": "2022-08-23T23:02:18.455Z", "updated_at": "2022-08-23T23:02:18.455Z" }, "resource": "environment=env-abc123", "resource_type": "ENVIRONMENT", "current_state": "DISABLED" } ``` The following example shows how to unmute notifications for an environment. ```none PATCH /notifications/v1/resource-preferences HTTP/1.1 Host: api.confluent.cloud { "resource": "environment=env-abc123", "resource_type": "ENVIRONMENT", "current_state": "ENABLED" } ``` ### Manage notifications for clusters You can manage notifications for a cluster resource using the Cloud Console or REST API. ### Cloud Console To manage notifications for a cluster, on the cluster overview page, select the **Settings** tab, and access the **Notifications** section to manage notifications for that cluster. The following image shows **Manage notifications** for the cluster grayed out, meaning the user does not have permissions to manage notifications for that cluster. ![image](images/_monitoring/cluster-settings-notifications-section.png) To learn more about configuring integrations for cluster notifications, see [Configure integrations and subscriptions](#configure-integrations). ### REST API To manage notifications for a cluster, you make calls to the `/notifications/v1/resource-subscriptions` endpoint, specifying `CLUSTER` as the `resource_type` in the request. You can create, update, and delete resource subscriptions for cluster notifications using the REST API. The request must include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). The following example shows how to create a resource subscription for cluster notifications by sending a POST request to the `resource-subscriptions` endpoint with a JSON payload that specifies the cluster resource and the integration ID. To learn how to create an integration, see [Configure integrations and subscriptions](#configure-integrations). ```none POST /notifications/v1/resource-subscriptions HTTP/1.1 Host: api.confluent.cloud { "resource": "cloud-cluster=lkc-abc123", "resource_type": "CLUSTER", "current_state": "ENABLED", "notification_type": { "id": "nt-abc123" }, "integrations": [ { "id": "i-e0KrA" } ] } ``` A successful response is `201 Created` with a JSON payload containing the created resource subscription. To learn more about configuring integrations for cluster notifications, see [Configure integrations and subscriptions](#configure-integrations). ### Manage notifications for topics You can manage notifications for a Tableflow-enabled topic using the Cloud Console or REST API. You can only subscribe to one Tableflow-enabled topic in a cluster at a time. ### Cloud Console To manage notifications for a topic, on the topic overview page, select the **Settings** tab. In the **Notifications** section, click **Manage notifications**. ![Notifications section on a topic's Settings tab. Includes a Manage notifications button.](images/_monitoring/topic-notifications-manage-button.png) To learn more about configuring integrations, see [Configure integrations and subscriptions](#configure-integrations). To learn more about Tableflow notification types, see [Monitor Tableflow](../topics/tableflow/operate/monitor-tableflow.md#tableflow-monitor). ### REST API To manage notifications for a topic, you make calls to the `/notifications/v1/resource-subscriptions` endpoint, specifying `TOPIC` as the `resource_type` in the request. You can create, update, and delete resource subscriptions for topic notifications using the REST API. The request must include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). The following example shows how to create a resource subscription for topic notifications by sending a POST request to the `resource-subscriptions` endpoint with a JSON payload that specifies the topic resource and the integration ID. Unlike the cluster and connector examples, the `resource` field for a topic is a CRN that includes the organization, environment, and cluster IDs. The same cluster ID appears twice: once as `cloud-cluster` and once as `kafka`. To learn how to create an integration, see [Configure integrations and subscriptions](#configure-integrations). ```none POST /notifications/v1/resource-subscriptions HTTP/1.1 Host: api.confluent.cloud { "resource": "crn://confluent.cloud/organization=00000000-0000-0000-0000-000000000000/environment=env-abc123/cloud-cluster=lkc-abc123/kafka=lkc-abc123/topic=my-topic", "resource_type": "TOPIC", "current_state": "ENABLED", "notification_type": { "id": "nt-abc123" }, "integrations": [ { "id": "i-e0KrA" } ] } ``` A successful response is `201 Created` with a JSON payload containing the created resource subscription. ### Manage notifications for connectors You can manage notifications at the connector level using the Cloud Console or REST API. ### Cloud Console To manage notifications for a connector, on the connector overview page, select the **Settings** tab and you see a **Notifications** section. Click **Manage notifications** to configure notifications. ![image](images/_monitoring/connector-notifications-manage-button.png) A side panel opens where you can configure integrations and subscriptions for that connector. To learn more about configuring integrations, see [Configure integrations and subscriptions](#configure-integrations). To learn more about connector notification types, see [Connector notifications and state transitions](#ccloud-connector-notifications). ### REST API To manage notifications for a connector, you make calls to the `/notifications/v1/resource-subscriptions` endpoint, specifying `CONNECTOR` as the `resource_type` in the request. You can create, update, and delete resource subscriptions for connector notifications using the REST API. The request must include an authentication header that contains an API key and secret scoped for resource management, Base64 encoded. For more about authentication, see [Authentication](https://docs.confluent.io/cloud/current/api.html/#authentication). The following example shows how to update a resource subscription for connector notifications by sending a PATCH request that specifies the `resource_type` as `CONNECTOR`, the `current_state` to trigger the connector notification, and a JSON payload that specifies the integration ID and the updates to make. To learn how to create an integration, see [Configure integrations and subscriptions](#configure-integrations). ```none PATCH /notifications/v1/resource-subscriptions/{id} HTTP/1.1 Host: api.confluent.cloud { "resource": "cloud-connector=lcc-abc123", "resource_type": "CONNECTOR", "current_state": "DISABLED", "integrations": [ { "id": "i-e0KrA" } ] } ``` A successful response is `200 OK` with a JSON payload containing the updated resource subscription. ```none POST /notifications/v1/resource-subscriptions HTTP/1.1 Host: api.confluent.cloud { "resource": "cloud-connector=lcc-abc123", "resource_type": "CONNECTOR", "current_state": "ENABLED", "notification_type": { "id": "nt-abc123" }, "integrations": [ { "id": "i-e0KrA" } ] } ``` ## Notification reference ### Notification severity levels Notifications have the following severity levels: - **Critical**: High-impact notifications that need immediate attention. Address these notifications with priority. - **Warn**: Warning notifications you can address now or later. - **Info**: Informational notifications about the normal operation of your cluster. ### Required notifications The following table describes required notifications. | Severity level | Category | Description | |------------------|-----------------------|-----------------------------------------------------------------------------| | Critical | Account | Organization has been suspended (end of free trial). | | Critical | Service | Access to a customer-managed encryption key (BYOK) has been disrupted. | | Warn | Billing and licensing | Free usage is 80% consumed or free usage expires in three days. | | Warn | Security | Security Assertion Markup Language (SAML) certificate is expiring
soon. | | Warn | Security | OrganizationAdmin Role Binding Granted. | | Warn | Security | OrganizationAdmin Email Changed. | | Warn | Service | Connector plugin no longer supported. | ### Recommended notifications The following table describes recommended notifications. | Severity level | Category | Description | |------------------|------------------------|----------------------------| | Warn | Unified Stream Manager | Metrics delayed. | | Critical | Unified Stream Manager | Cluster in critical state. | | Critical | Unified Stream Manager | Partitions Offline. | | Critical | Unified Stream Manager | Broker Storage Over 80%. | | Critical | Unified Stream Manager | Network Pool Over 80%. | | Critical | Unified Stream Manager | Request Pool Over 80%. | | Critical | Unified Stream Manager | Connector Stopped Running. | To learn more about Unified Stream Manager alert types, see [Monitor Alerts for Confluent Platform Resources with Unified Stream Manager](../usm/monitor/alerts.md#platform-alerts). ### Optional notifications The following table describes optional notifications. | Severity level | Category | Description | |------------------|-----------------------|----------------------------------------------------------| | Info | Billing and licensing | 30 days have elapsed since org was created. | | Info | Billing and licensing | 50% or more of free trial usage consumed. | | Critical | Service | Kafka cluster expansion failure. | | Critical | Service | Cloud Service Quota reached 100% usage. | | Critical | Service | Connector in FAILED state. | | Critical | Service | Apache Flink® statement failure. | | Warn | Service | Kafka cluster shrink failure. | | Warn | Service | Cloud Service Quota surpassed 90% usage. | | Warn | Service | Flink statement degraded. | | Warn | Service | Flink statement auto-stopped. | | Info | Service | Kafka cluster expansion complete. | | Info | Service | Kafka cluster shrink complete. | | Info | Service | Cloud Service Quota surpassed 50% usage. | | Info | Service | Connector state transition from PROVISIONING to RUNNING. | | Info | Service | Tableflow started syncing on a topic. | | Critical | Service | Tableflow syncing failed on a topic. | | Warn | Service | Tableflow stuck in pending state on a topic. | | Critical | Service | Tableflow topic degraded. | | Critical | Service | External catalog sync failed. | ## Connector notifications and state transitions In the Cloud Console, you can enable or disable notifications for connectors using the **Manage notifications** feature. ![image](images/_monitoring/notification-connector-state-transition.png) If you enable this feature, Confluent Cloud sends a notification to your desired notification channels, such as email, Slack, Microsoft Teams, or generic webhook, when the connector transitions to or from either one of the following states: - [Provisioning to Running](#ccloud-connector-provisioning-to-running) - [Provisioning to Failed](#ccloud-connector-provisioning-to-failed) - [Running to Failed](#ccloud-connector-running-to-failed) Each notification message includes the following content: - Status of the connector (Running or Failed) - Connector name - Connector ID - Cluster ID You can troubleshoot any issue further by clicking **View connector** from the message content as shown in the following example: ![image](images/_monitoring/connector-failed-email.png) The following sections describe connector state transitions and their notification types. ### Provisioning to Running When you first launch a connector, it enters the `PROVISIONING` state. If the connector launches successfully, the connector state changes to `RUNNING`. After this occurs, Confluent Cloud sends you a notification about the new connector to the selected notification channels denoting the connector is up and running. ### Provisioning to Failed The connector can transition from `PROVISIONING` to `FAILED` state for several reasons, including: - A system error - The connector failed to start due to an error - API keys resource-scoped for Kafka clusters are not propagated to the data plane - Schema Registry role bindings are not propagated to the data plane If any of these situations occur, Confluent Cloud sends a notification message to your desired notification channels denoting the connector failed. ### Running to Failed If all connector tasks fail, the connector enters the `FAILED` state. A running connector can go into `FAILED` state for a number of reasons, including: - Configuration validation errors - Network connectivity issues If any of these situations occur, Confluent Cloud sends a notification message to your desired notification channels denoting the connector failed. #### NOTE To prevent email spam, Confluent Cloud deduplicates repeated failure notifications based on connector ID, status (`FAILED` or `DEGRADED`), and configuration version. Always check the Confluent Cloud Console for the most current connector status and real-time error details. * Error messages: Different errors do not trigger separate alerts. A connector facing multiple unique errors during the same window sends only a single notification. * Window reset: The deduplication window spans a UTC calendar day, resetting at 00:00 UTC or when the connector configuration is successfully updated. * Restarts: Restarting a connector does not reset the deduplication window. ## Related content - [Confluent Cloud APIs](https://docs.confluent.io/cloud/current/api.html) - [Observability for Kafka Clients to Confluent Cloud](ccloud-observability.md#ccloud-observability-index) - [Confluent Cloud Metrics](metrics-api.md#metrics-api) - [Monitor Tableflow](../topics/tableflow/operate/monitor-tableflow.md#tableflow-monitor)