OSDOCS-8938: Cluster notifications docs for Managed OpenShift

_topic_maps/_topic_map_osd.yml

@@ -339,6 +339,9 @@ Name: Cluster administration
 Dir: osd_cluster_admin
 Distros: openshift-dedicated
 Topics:
+- Name: Cluster notifications
+  File: osd-cluster-notifications
+  Distros: openshift-dedicated
 - Name: Configuring private connections
   Dir: osd_private_connections
   Distros: openshift-dedicated

_topic_maps/_topic_map_rosa.yml

@@ -554,6 +554,9 @@ Topics:
 #   File: rosa-cluster-auth
 # - Name: Authorization and RBAC
 #   File: rosa-auth-rbac
+- Name: Cluster notifications
+  File: rosa-cluster-notifications
+  Distros: openshift-rosa
 - Name: Configuring private connections
   Dir: cloud_infrastructure_access
   Distros: openshift-rosa

_topic_maps/_topic_map_rosa_hcp.yml

@@ -541,17 +541,20 @@ Topics:
 #    File: ocm-overview
 #  - Name: Using the OpenShift web console
 #    File: rosa-using-openshift-console
-# ---
-# Name: Cluster administration
-# Dir: rosa_cluster_admin
-# Distros: openshift-rosa-hcp
-# Topics:
+---
+Name: Cluster administration
+Dir: rosa_cluster_admin
+Distros: openshift-rosa-hcp
+Topics:
 #  - Name: Cluster configurations
 #    File: rosa-cluster-config
 #  - Name: Cluster authentication
 #    File: rosa-cluster-auth
 #  - Name: Authorization and RBAC
 #    File: rosa-auth-rbac
+  - Name: Cluster notifications
+    File: rosa-cluster-notifications
+    Distros: openshift-rosa-hcp
 # - Name: Configuring private connections
 #   Dir: cloud_infrastructure_access
 #   Distros: openshift-rosa-hcp

modules/managed-cluster-add-notification-contacts.adoc

@@ -0,0 +1,29 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-notifications.adoc
+// * osd_cluster_admin/osd-cluster-notifications.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="add-notification-contact_{context}"]
+= Adding notification contacts to your cluster
+
+Notification contacts receive emails when cluster notifications are sent to the cluster.
+By default, only the cluster owner receives cluster notification emails. You can configure other cluster users as additional notification contacts in your cluster support settings.
+
+.Prerequisites
+* Your cluster is deployed and registered to the {hybrid-console}.
+* You are logged in to the {hybrid-console-second}.
+* The intended notification recipient has a user account on your cluster.
+
+.Procedure
+. Navigate to the Clusters page of the {hybrid-console-second}.
+. Click the name of your cluster to go to the cluster details page.
+. Click the **Support** tab.
+. On the **Support** tab, find the **Notification contacts** section.
+. Click **Add notification contact**.
+. In the **Red Hat username or email** field, enter the email address or the user name of the new recipient.
+//. In the type field, select the types of cluster notification to send to this recipient.
+. Click **Add contact**.
+
+.Verification steps
+* The "Notification contact added successfully" message displays.

modules/managed-cluster-configure-notification-types-received.adoc

@@ -0,0 +1,31 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-notifications.adoc
+// * osd_cluster_admin/osd-cluster-notifications.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="config-notification-types-received_{context}"]
+= Configuring notification types received
+
+Notification contacts receive emails when cluster notifications are sent to the cluster.
+
+By default, a notification contact receives an email for every notification sent to the cluster, regardless of notification type. You can configure the type of notification you want to receive in the {hybrid-console} notification settings for OpenShift.
+
+.Prerequisites
+* Your cluster is deployed and registered to the {hybrid-console-second}.
+* You are logged in to the {hybrid-console-second}.
+
+.Procedure
+. Log in to the {hybrid-console-second}.
+. Click **Settings** -> **Notifications** to open the Notifications overview.
+. Click **Notification Preferences**.
+. On the My Notifications page, under OpenShift, click **Cluster Manager**.
+. Specify the notification types that you want to receive by selecting or clearing the relevant checkbox.
+. Click **Save**.
+
+.Verification steps
+* The "Notification preferences successfully saved" message displays.
+
+// .Additional resources
+// * Cluster notification types
+// * Configuring notifications on Hybrid Cloud Console

modules/managed-cluster-notification-policy.adoc

@@ -0,0 +1,30 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-notifications.adoc
+// * osd_cluster_admin/osd-cluster-notifications.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="managed-cluster-notification-policy_{context}"]
+= Cluster notification policy
+
+Cluster notifications are designed to keep you informed about the health of your cluster and high impact events that affect it.
+
+Most cluster notifications are generated and sent automatically to ensure that you are immediately informed of problems or important changes to the state of your cluster.
+
+In certain situations, Red Hat Site Reliability Engineering (SRE) creates and sends cluster notifications to provide additional context and guidance for a complex issue.
+
+Cluster notifications are not sent for low-impact events, low-risk security updates, routine operations and maintenance, or minor, transient issues that are quickly resolved by SRE.
+
+Red Hat services automatically send notifications when:
+
+* Remote health monitoring or environment verification checks detect an issue in your cluster, for example, when a worker node has low disk space.
+* Significant cluster life cycle events occur, for example, when scheduled maintenance or upgrades begin, or cluster operations are impacted by an event, but do not require customer intervention.
+* Significant cluster management changes occur, for example, when cluster ownership or administrative control is transferred from one user to another.
+* Your cluster subscription is changed or updated, for example, when Red Hat makes updates to subscription terms or features available to your cluster.
+
+SRE creates and sends notifications when:
+
+* An incident results in a degradation or outage that impacts your cluster's availability or performance, for example, your cloud provider has a regional outage. SRE sends subsequent notifications to inform you of incident resolution progress, and when the incident is resolved.
+* A security vulnerability, security breach, or unusual activity is detected on your cluster.
+* Red Hat detects that changes you have made are creating or may result in cluster instability.
+* Red Hat detects that your workloads are causing performance degradation or instability in your cluster.

modules/managed-cluster-notification-severity-levels.adoc

@@ -0,0 +1,18 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-notifications.adoc
+// * osd_cluster_admin/osd-cluster-notifications.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="managed-cluster-notification-severity_{context}"]
+= Cluster notification severity levels
+
+Each cluster notification has an associated severity level to help you identify notifications with the greatest impact to your business. You can filter cluster notifications according to these severity levels in the {hybrid-console}, in the **Cluster history** tab for your cluster.
+
+Red Hat uses the following severity levels for cluster notifications, from most to least severe:
+
+Critical:: Immediate action is required. One or more key functions of a service or cluster is not working, or will stop working soon. A critical alert is important enough to page on-call staff and interrupt regular workflows.
+Major:: Immediate action is strongly recommended. One or more key functions of the cluster will soon stop working. A major issue may lead to a critical issue if it is not addressed in a timely manner.
+Warning:: Action is required as soon as possible. One or more key functions of the cluster are not working optimally and may degrade further, but do not pose an immediate danger to the functioning of the cluster.
+Info:: No action necessary. This severity does not describe problems that need to be addressed, only important information about meaningful or important life cycle, service, or cluster events.
+Debug:: No action necessary. Debug notifications provide low-level information about less important lifecycle, service, or cluster events to aid in debugging unexpected behavior.

modules/managed-cluster-notification-types.adoc

@@ -0,0 +1,32 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-notifications.adoc
+// * osd_cluster_admin/osd-cluster-notifications.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="managed-cluster-notification-types_{context}"]
+= Cluster notification types
+
+Each cluster notification has an associated notification type to help you identify notifications that are relevant to your role and responsibilities. You can filter cluster notifications according to these types in the {hybrid-console}, in the **Cluster history** tab for your cluster.
+
+Red Hat uses the following notification types to indicate notification relevance.
+
+Capacity management:: Notifications for events related to updating, creating, or deleting node pools, machine pools, compute replicas or quotas (load balancer, storage, etc.).
+Cluster access:: Notifications for events related to adding or deleting groups, roles or identity providers, for example, when SRE cannot access your cluster because STS credentials have expired, when there is a configuration problem with your AWS roles, or when you add or remove identity providers.
+Cluster add-ons:: Notifications for events related to add-on management or upgrade maintenance for add-ons, for example, when an add-on is installed, upgraded, or removed, or cannot be installed due to unmet requirements.
+Cluster configuration:: Notifications for cluster tuning events, workload monitoring, and inflight checks.
+Cluster lifecycle:: Notifications for cluster or cluster resource creation, deletion, and registration, or change in cluster or resource status (for example, ready or hibernating).
+Cluster networking:: Notifications related to cluster networking, including HTTP/S proxy, router, and ingress state.
+Cluster ownership:: Notifications related to cluster ownership transfer from one user to another.
+Cluster scaling:: Notifications related to updating, creating, or deleting node pools, machine pools, compute replicas or quota.
+Cluster security:: Events related to cluster security, for example, an increased number of failed access attempts, updates to trust bundles, or software updates with security impact.
+Cluster subscription:: Cluster expiration, trial cluster notifications, or switching from free to paid.
+Cluster updates:: Anything relating to upgrades, such as upgrade maintenance or enablement.
+Customer support:: Updates on support case status.
+General notification:: The default notification type. This is only used for notifications that do not have a more specific category.
+// Omitted, as no definition provided as part of OSDOCS-8938
+// cluster-state-updates
+// clustercreate-details
+// clustercreate-high-level
+// clusterremove-details
+// clusterremove-high-level

modules/managed-cluster-notification-view-in-hcc.adoc

@@ -0,0 +1,29 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-notifications.adoc
+// * osd_cluster_admin/osd-cluster-notifications.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="managed-cluster-notification-view-hcc_{context}"]
+= Viewing cluster notifications using the {hybrid-console}
+
+Cluster notifications provide important information about the health of your cluster. You can view notifications that have been sent to your cluster in the **Cluster history** tab on the {hybrid-console}.
+
+.Prerequisites
+* You are logged in to the {hybrid-console-second}.
+
+.Procedure
+. Navigate to the link:https://console.redhat.com/openshift[Clusters] page of the {hybrid-console-second}.
+. Click the name of your cluster to go to the cluster details page.
+. Click the **Cluster history** tab.
++
+Cluster notifications appear under the Cluster history heading.
+. Optional: Filter for relevant cluster notifications
++
+Use the filter controls to hide cluster notifications that are not relevant to you, so that you can focus on your area of expertise or on resolving a critical issue. You can filter notifications based on text in the notification description, severity level, notification type, when the notification was received, and which system or person triggered the notification.
+
+// .Additional resources
+// * Cluster notification types
+// * Cluster notification severity levels
+// * Cluster notification emails
+// * Troubleshooting: Cluster notifications

modules/managed-cluster-remove-notification-contacts.adoc

@@ -0,0 +1,27 @@
+// Module included in the following assemblies:
+//
+// * rosa_cluster_admin/rosa-cluster-notifications.adoc
+// * osd_cluster_admin/osd-cluster-notifications.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="remove-notification-contact_{context}"]
+= Removing notification contacts from your cluster
+
+Notification contacts receive emails when cluster notifications are sent to the cluster.
+
+You can remove notification contacts in your cluster support settings to prevent them from receiving notification emails.
+
+.Prerequisites
+* Your cluster is deployed and registered to the {hybrid-console}.
+* You are logged in to the {hybrid-console-second}.
+
+.Procedure
+. Navigate to the Clusters page of the {hybrid-console-second}.
+. Click the name of your cluster to go to the cluster details page.
+. Click the **Support** tab.
+. On the **Support** tab, find the **Notification contacts** section.
+. Click the options menu (**⚙**) beside the recipient you want to remove.
+. Click **Delete**.
+
+.Verification steps
+* The "Notification contact deleted successfully" message displays.

modules/policy-incident.adoc

@@ -5,8 +5,9 @@
 [id="policy-incident_{context}"]
 = Incident and operations management
 
-
-This documentation details the Red Hat responsibilities for the {product-title} managed service.
+This documentation details the Red Hat responsibilities for the {product-title} managed service. 
+The cloud provider is responsible for protecting the hardware infrastructure that runs the services offered by the cloud provider.
+The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.
 
 [id="platform-monitoring_{context}"]
 == Platform monitoring
@@ -27,18 +28,6 @@ The general workflow of how a new incident is managed by Red Hat:
 . The incident is documented and a root cause analysis is performed within 5 business days of the incident.
 . A root cause analysis (RCA) draft document is shared with the customer within 7 business days of the incident.
 
-[id="notifications_{context}"]
-== Notifications
-Platform notifications are configured using email. Any customer notification is also sent to the corresponding Red Hat account team and if applicable, the Red Hat Technical Account Manager.
-
-The following activities can trigger notifications:
-
-* Platform incident
-* Performance degradation
-* Cluster capacity warnings
-* Critical vulnerabilities and resolution
-* Upgrade scheduling
-
 [id="backup-recovery_{context}"]
 == Backup and recovery
 All {product-title} clusters are backed up using cloud provider snapshots. Notably, this does not include customer data stored on persistent volumes (PVs). All snapshots are taken using the appropriate cloud provider snapshot APIs and are uploaded to a secure object storage bucket (S3 in AWS, and GCS in Google Cloud) in the same account as the cluster.

modules/policy-shared-responsibility.adoc

@@ -10,7 +10,7 @@ The customer and Red Hat share responsibility for the monitoring and maintenance
 
 [id="incident-operations-management_{context}"]
 == Incident and operations management
-The customer is responsible for incident and operations management of customer application data and any custom networking the customer might have configured for the cluster network or virtual network.
+The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.
 
 [cols= "2a,3a,3a",options="header"]
 |===

modules/rosa-policy-incident.adoc

@@ -6,7 +6,7 @@
 = Incident and operations management
 
 Red Hat is responsible for overseeing the service components required for default platform networking.
-AWS is responsible for protecting the hardware infrastructure that runs all of the services offered in the AWS Cloud. The customer is responsible for incident and operations management of customer application data and any custom networking the customer may have configured for the cluster network or virtual network.
+AWS is responsible for protecting the hardware infrastructure that runs all of the services offered in the AWS Cloud. The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.
 
 [cols= "2a,3a,3a",options="header"]
 |===
@@ -116,18 +116,6 @@ Red Hat can assist with activities including but not limited to:
 * Guiding compute image collection
 * Providing collected audit logs
 
-[id="rosa-policy-notifications_{context}"]
-== Notifications
-Platform notifications are configured using email. Some customer notifications are also sent to an account's corresponding Red Hat account team, including a Technical Account Manager, if applicable.
-
-The following activities can trigger notifications:
-
-- Platform incident
-- Performance degradation
-- Cluster capacity warnings
-- Critical vulnerabilities and resolution
-- Upgrade scheduling
-
 //Note: The following content will be used again in the future (per OSDOCS:4654)
 //[id="backup-recovery_{context}"]
 //== Backup and recovery

modules/rosa-sdpolicy-monitoring.adoc

@@ -16,6 +16,6 @@ This section provides information about the service definition for {product-titl
 {product-title} clusters come with an integrated Prometheus stack for cluster monitoring including CPU, memory, and network-based metrics. This is accessible through the web console. These metrics also allow for horizontal pod autoscaling based on CPU or memory metrics provided by an {product-title} user.
 
 [id="rosa-sdpolicy-cluster-status-notifications_{context}"]
-== Cluster status notification
+== Cluster notifications
 
-Red Hat communicates the health and status of {product-title} clusters through a combination of a cluster dashboard available in {cluster-manager}, and email notifications sent to the email address of the contact that originally deployed the cluster, and any additional contacts specified by the customer.
+include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]

modules/sdpolicy-monitoring.adoc

@@ -11,6 +11,6 @@
 {product-title} clusters come with an integrated Prometheus/Grafana stack for cluster monitoring including CPU, memory, and network-based metrics. This is accessible through the web console and can also be used to view cluster-level status and capacity/usage through a Grafana dashboard. These metrics also allow for horizontal pod autoscaling based on CPU or memory metrics provided by an {product-title} user.
 
 [id="cluster-status-notification_{context}"]
-== Cluster status notification
+== Cluster notifications
 
-Red Hat communicates the health and status of {product-title} clusters through a combination of a cluster dashboard available in  {cluster-manager-first}, and email notifications sent to the email address of the contact that originally deployed the cluster.
+include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]

osd_architecture/osd_policy/policy-process-security.adoc

@@ -6,6 +6,13 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 
 toc::[]
 
+[id="review-action-notifications_{context}"]
+== Review and action cluster notifications
+
+include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]
+include::modules/managed-cluster-notification-policy.adoc[leveloffset=+2]
+
+//---
 
 include::modules/policy-incident.adoc[leveloffset=+1]
 include::modules/policy-change-management.adoc[leveloffset=+1]

osd_cluster_admin/osd-cluster-notifications.adoc

@@ -0,0 +1,53 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="osd-cluster-notifications"]
+= Cluster notifications
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: osd-cluster-notifications
+
+toc::[]
+
+include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]
+
+[role="_additional-resources"]
+== Additional resources
+* xref:../osd_architecture/osd_policy/policy-process-security.adoc#notifications_policy-process-security[Customer responsibilities: Review and action cluster notifications]
+* xref:#cluster-notification-emails_osd-cluster-notifications[Cluster notification emails]
+* xref:#troubleshoot_osd-cluster-notifications[Troubleshooting: Cluster notifications]
+
+[id="expectations_{context}"]
+== What to expect from cluster notifications
+
+As a cluster administrator, you need to be aware of when and why cluster notifications are sent, as well as their types and severity levels, in order to effectively understand the health and administration needs of your cluster.
+
+include::modules/managed-cluster-notification-policy.adoc[leveloffset=+2]
+
+include::modules/managed-cluster-notification-severity-levels.adoc[leveloffset=+2]
+
+include::modules/managed-cluster-notification-types.adoc[leveloffset=+2]
+
+include::modules/managed-cluster-notification-view-in-hcc.adoc[leveloffset=+1]
+
+[id="cluster-notification-emails_{context}"]
+== Cluster notification emails
+
+By default, when a cluster notification is sent to the cluster, it is also sent as an email to the cluster owner. You can configure additional recipients for notification emails to ensure that all appropriate users remain informed about the state of the cluster.
+
+include::modules/managed-cluster-add-notification-contacts.adoc[leveloffset=+2]
+
+//TODO OSDOCS-8938: This doesn't actually work as intended as far as Laura can tell; OpenShift users can't unsubscribe from all types using this method - need to check in with Abhishek about this.
+//include::modules/managed-cluster-configure-notification-types-received.adoc[leveloffset=+1]
+
+include::modules/managed-cluster-remove-notification-contacts.adoc[leveloffset=+2]
+
+[id="troubleshoot_{context}"]
+== Troubleshooting
+
+.If you are not receiving cluster notification emails
+* Ensure that emails sent from `@redhat.com` addresses are not filtered out of your email inbox.
+* Ensure that your correct email address is listed as a notification contact for the cluster.
+* Ask the cluster owner or administrator to add you as a notification contact:
+xref:#cluster-notification-emails_osd-cluster-notifications[Cluster notification emails].
+
+.If your cluster does not receive notifications
+* Ensure that your cluster can access resources at `api.openshift.com`.
+* Ensure that your firewall is configured according to the documented prerequisites: xref:../osd_planning/aws-ccs.adoc#osd-aws-privatelink-firewall-prerequisites_aws-ccs[AWS firewall prerequisites]

rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc

@@ -11,6 +11,14 @@ This documentation outlines Red Hat, Amazon Web Services (AWS), and customer res
 include::modules/rosa-policy-responsibilities.adoc[leveloffset=+1]
 include::modules/rosa-policy-shared-responsibility.adoc[leveloffset=+1]
 
+[id="review-action-notifications_{context}"]
+== Review and action cluster notifications
+
+include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]
+include::modules/managed-cluster-notification-policy.adoc[leveloffset=+2]
+
+//---
+
 include::modules/rosa-policy-incident.adoc[leveloffset=+1]
 include::modules/rosa-policy-change-management.adoc[leveloffset=+1]
 include::modules/rosa-policy-security-and-compliance.adoc[leveloffset=+1]

rosa_cluster_admin/rosa-cluster-notifications.adoc

@@ -0,0 +1,52 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="rosa-cluster-notifications"]
+= Cluster notifications
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: rosa-cluster-notifications
+
+toc::[]
+
+include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]
+
+[role="_additional-resources"]
+== Additional resources
+* xref:../rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc#notifications_rosa-policy-responsibility-matrix[Customer responsibilities: Review and action cluster notifications]
+* xref:#cluster-notification-emails_rosa-cluster-notifications[Cluster notification emails]
+* xref:#troubleshoot_rosa-cluster-notifications[Troubleshooting: Cluster notifications]
+
+[id="expectations_{context}"]
+== What to expect from cluster notifications
+
+As a cluster administrator, you need to be aware of when and why cluster notifications are sent, as well as their types and severity levels, in order to effectively understand the health and administration needs of your cluster.
+
+include::modules/managed-cluster-notification-policy.adoc[leveloffset=+2]
+
+include::modules/managed-cluster-notification-severity-levels.adoc[leveloffset=+2]
+
+include::modules/managed-cluster-notification-types.adoc[leveloffset=+2]
+
+include::modules/managed-cluster-notification-view-in-hcc.adoc[leveloffset=+1]
+
+[id="cluster-notification-emails_{context}"]
+== Cluster notification emails
+
+By default, when a cluster notification is sent to the cluster, it is also sent as an email to the cluster owner. You can configure additional recipients for notification emails to ensure that all appropriate users remain informed about the state of the cluster.
+
+include::modules/managed-cluster-add-notification-contacts.adoc[leveloffset=+2]
+
+//TODO OSDOCS-8938: This doesn't actually work as intended as far as Laura can tell; OpenShift users can't unsubscribe from all types using this method - need to check in with Abhishek about this.
+//include::modules/managed-cluster-configure-notification-types-received.adoc[leveloffset=+1]
+
+include::modules/managed-cluster-remove-notification-contacts.adoc[leveloffset=+2]
+
+[id="troubleshoot_{context}"]
+== Troubleshooting
+
+.If you are not receiving cluster notification emails
+* Ensure that emails sent from `@redhat.com` addresses are not filtered out of your email inbox.
+* Ensure that your correct email address is listed as a notification contact for the cluster.
+* Ask the cluster owner or administrator to add you as a notification contact: xref:#cluster-notification-emails_rosa-cluster-notifications[Cluster notification emails].
+
+.If your cluster does not receive notifications
+* Ensure that your cluster can access resources at `api.openshift.com`.
+* Ensure that your firewall is configured according to the documented prerequisites: xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS firewall prerequisites]

rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc

@@ -124,6 +124,7 @@ include::modules/rosa-hcp-sts-creating-a-cluster-cli.adoc[leveloffset=+1]
 == Next steps
 
 * xref:../rosa_install_access_delete_clusters/rosa-sts-accessing-cluster.adoc#rosa-sts-accessing-cluster[Accessing a ROSA cluster]
+* xref:../rosa_cluster_admin/rosa-cluster-notifications.adoc#add-notification-contact_rosa-cluster-notifications[Adding notification contacts]
 
 [role="_additional-resources"]
 [id="additional-resources_rosa-sts-creating-a-cluster-quickly"]

rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc

@@ -14,7 +14,8 @@ include::modules/rosa-aws-privatelink-create-cluster.adoc[leveloffset=+1]
 include::modules/osd-aws-privatelink-config-dns-forwarding.adoc[leveloffset=+1]
 
 == Next steps
-xref:../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.adoc#rosa-sts-config-identity-providers[Configure identity providers]
+* xref:../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.adoc#rosa-sts-config-identity-providers[Configure identity providers]
+* xref:../rosa_cluster_admin/rosa-cluster-notifications.adoc#add-notification-contact_rosa-cluster-notifications[Adding notification contacts]
 
 [role="_additional-resources"]
 == Additional resources

rosa_install_access_delete_clusters/rosa-sts-accessing-cluster.adoc

@@ -30,3 +30,4 @@ include::modules/rosa-create-dedicated-cluster-admins.adoc[leveloffset=+1]
 == Additional resources
 * xref:../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.adoc#rosa-sts-config-identity-providers[Configuring identity providers using {cluster-manager-first} console]
 * xref:../rosa_getting_started/rosa-sts-getting-started-workflow.adoc#rosa-sts-understanding-the-deployment-workflow[Understanding the ROSA with STS deployment workflow]
+* xref:../rosa_cluster_admin/rosa-cluster-notifications.adoc#add-notification-contact_rosa-cluster-notifications[Adding notification contacts]

rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc

@@ -49,6 +49,7 @@ include::modules/rosa-sts-creating-a-cluster-quickly-cli.adoc[leveloffset=+1]
 == Next steps
 
 * xref:../rosa_install_access_delete_clusters/rosa-sts-accessing-cluster.adoc#rosa-sts-accessing-cluster[Accessing a ROSA cluster]
+* xref:../rosa_cluster_admin/rosa-cluster-notifications.adoc#add-notification-contact_rosa-cluster-notifications[Adding notification contacts]
 
 [role="_additional-resources"]
 [id="additional-resources_rosa-sts-creating-a-cluster-quickly"]

rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-with-customizations.adoc

@@ -54,6 +54,7 @@ include::modules/rosa-sts-creating-a-cluster-with-customizations-cli.adoc[levelo
 == Next steps
 
 * xref:../rosa_install_access_delete_clusters/rosa-sts-accessing-cluster.adoc#rosa-sts-accessing-cluster[Accessing a ROSA cluster]
+* xref:../rosa_cluster_admin/rosa-cluster-notifications.adoc#add-notification-contact_rosa-cluster-notifications[Adding notification contacts]
 
 [role="_additional-resources"]
 [id="additional-resources_rosa-sts-creating-a-cluster-with-customizations"]

snippets/managed-openshift-about-cluster-notifications.adoc

@@ -0,0 +1,9 @@
+Cluster notifications are messages about the status, health, or performance of your cluster.
+
+Cluster notifications are the primary way that Red Hat Site Reliability Engineering (SRE) communicates with you about the health of your managed cluster. SRE may also use cluster notifications to prompt you to perform an action in order to resolve or prevent an issue with your cluster.
+//OSDOCS-8938: Omitted until an SME confirms this is true
+//For incident management purposes, notifications are also sent to your Red Hat account team, including your Technical Account Manager, if applicable.
+
+Cluster owners and administrators must regularly review and action cluster notifications to ensure clusters remain healthy and supported.
+
+You can view cluster notifications in the {hybrid-console}, in the **Cluster history** tab for your cluster. By default, only the cluster owner receives cluster notifications as emails. If other users need to receive cluster notification emails, add each user as a notification contact for your cluster.