DOC-2202: Document Serverless maintenance behavior (#591)

* DOC-2202: Document Serverless maintenance behavior

Add a Serverless maintenance section to the Upgrades and Maintenance
page covering multi-tenant operation, the lack of configurable
maintenance windows, and the typical upgrade cadence. Cross-reference
the new section from the Serverless cluster type page so customers and
Support can find an authoritative answer.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* edits

* Add page metadata and learning objectives

Add :page-topic-type:, :personas:, and :learning-objective-N: attributes
to the Upgrades and Maintenance and Serverless pages, plus the checkbox
display block, so both pages conform to the docs-team-standards content
architecture guide.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* edit

* minor edit

* coderabbit suggestion

* address review: clarify operations run at any time

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* add to list of beta features in overview + move note

* Update modules/get-started/pages/cluster-types/serverless.adoc

Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

* incorporate doc review feedback

* split steps for clarify

* minor edit

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Joyce Fee <102751339+Feediver1@users.noreply.github.com>

Author: 3 people

modules/get-started/pages/cloud-overview.adoc

@@ -420,7 +420,7 @@ Features in limited availability are production-ready and are covered by Redpand
 
 The following features are currently in limited availability in Redpanda Cloud:
 
-* xref:ai-agents:adp-overview.adoc[Redpanda ADP] including AI agents, AI Gateway, and transcripts
+* xref:ai-agents:adp-overview.adoc[Redpanda Agentic Data Plane (ADP)]
 * Dedicated for Azure
 
 == Features in beta
@@ -429,7 +429,8 @@ Features in beta are available for testing and feedback. They are not covered by
 
 The following features are currently in beta in Redpanda Cloud:
 
-* BYOVNet for Azure
+* Serverless on GCP
+* BYOVNet on Azure
 * Secrets management for BYOVPC on GCP
 * Several Redpanda Connect components 
 

modules/get-started/pages/cluster-types/serverless.adoc

@@ -1,15 +1,20 @@
 = Serverless
 :description: Learn how to create a Serverless cluster and start streaming.
-:page-aliases: get-started:cluster-types/serverless-pro.adoc, ROOT:deploy:deployment-option/cloud/serverless.adoc 
+:page-aliases: get-started:cluster-types/serverless-pro.adoc, ROOT:deploy:deployment-option/cloud/serverless.adoc
+:page-topic-type: overview
+:personas: evaluator, app_developer, platform_admin
+:learning-objective-1: Identify the use cases and usage limits for Serverless clusters
+:learning-objective-2: Describe how to create a Serverless cluster and connect a client
+:learning-objective-3: Recognize which features are supported and unsupported on Serverless
 
 
-Serverless is the fastest and easiest way to start data streaming. With Serverless clusters, you host your data in Redpanda's VPC, and Redpanda handles automatic scaling, provisioning, operations, and maintenance. This is a production-ready deployment option with a cluster available instantly, and you only pay for what you consume. You can view detailed billing activity for each cluster and edit payment methods on the *Billing* page. 
+Serverless is the fastest and easiest way to start data streaming. With Serverless clusters, you host your data in Redpanda's VPC, and Redpanda handles automatic scaling, provisioning, operations, and maintenance. This is a production-ready deployment option with a cluster available instantly, and you only pay for what you consume. You can view detailed billing activity for each cluster and edit payment methods on the *Billing* page.
 
-[NOTE]
-====
-Serverless on GCP is currently in a glossterm:beta[] release. 
+After reading this page, you will be able to:
 
-====
+* [ ] {learning-objective-1}
+* [ ] {learning-objective-2}
+* [ ] {learning-objective-3}
 
 == Serverless usage limits
 
@@ -43,6 +48,12 @@ Make sure you have the latest version of `rpk`, the Redpanda CLI. See xref:get-s
 
 == Get started with Serverless
 
+[NOTE]
+====
+Serverless on GCP is currently in a glossterm:beta[] release.
+
+====
+
 Choose the option that fits how you want to subscribe:
 
 include::get-started:partial$get-started-serverless.adoc[]
@@ -57,13 +68,15 @@ To create a Serverless cluster:
 +
 If you don't have an existing resource group, you can create one. Refresh the page to see newly-created resource groups. 
 
-. Select a cloud provider and xref:reference:tiers/serverless-regions.adoc[region]. For best performance, select the region closest to your applications. Redpanda expects your applications to be deployed in the same cloud provider and region as your Serverless cluster. 
-+
-Clusters on AWS can enable private access between their VPC and Redpanda, so data does not traverse the public internet. Private connectivity is implemented using AWS PrivateLink for secure traffic.
+. Select a cloud provider: AWS or GCP. (GCP is currently in a glossterm:beta[] release.)
+
+. Select a xref:reference:tiers/serverless-regions.adoc[region]. For best performance, select the region closest to your applications. Redpanda expects your applications to be deployed in the same cloud provider and region as your Serverless cluster. 
+
+. *AWS only*: Clusters on AWS can enable private access between their VPC and Redpanda, so data does not traverse the public internet. Private connectivity is implemented using AWS PrivateLink for secure traffic.
 +
 ** When you enable both public access and private access on the cluster, you can choose between the public address or the private address. When the public address is used the data flows over the public internet.
 ** You can either create a new PrivateLink or use an existing one from the same resource group.
-** You can enable or disable private access at any time on the cluster's *Settings* page. 
+** You can enable or disable private access at any time on the cluster's *Dataplane settings* page. 
 ** Enabling private access incurs additional charges.
 +
 NOTE: After private access is disabled, attempts to reach the private endpoints will fail. However, the PrivateLink endpoint in your AWS account and the PrivateLink resource in Redpanda Cloud both remain provisioned and continue to incur charges until you explicitly delete them.     
@@ -102,7 +115,17 @@ Not all features included in BYOC clusters are available in Serverless. For exam
 * Multiple availability zones (AZs)
 * Role-based access control (RBAC) in the data plane and mTLS authentication for Kafka API clients
 * Group-based access control (GBAC)
-* Kafka Connect 
+* Kafka Connect
+* Configurable maintenance windows
+
+[[maintenance-and-upgrades]]
+== Maintenance and upgrades
+
+Redpanda manages all maintenance for Serverless clusters. Because Serverless runs on shared, multi-tenant infrastructure, you cannot configure a maintenance window or schedule upgrades for an individual cluster. Redpanda may run maintenance operations on Serverless clusters at any time. Continuous operations are integral to keeping Serverless clusters up to date and secure. Operations run in a rolling fashion and are designed to be non-disruptive. Mainstream Kafka client libraries reconnect automatically when broker connections restart.
+
+If you need control over when maintenance runs on your cluster, use a Dedicated or BYOC cluster, both of which support configurable maintenance windows.
+
+For more information, see xref:manage:maintenance.adoc[].
 
 == Next steps
 

modules/manage/pages/maintenance.adoc

@@ -1,20 +1,42 @@
 = Upgrades and Maintenance
 :description: Learn how Redpanda Cloud manages maintenance operations.
+:page-topic-type: concepts
+:personas: platform_admin, app_developer, streaming_developer
+:learning-objective-1: Compare minor upgrades, major upgrades, and deprecations and what to expect from each
+:learning-objective-2: Explain how scheduled maintenance windows work for BYOC and Dedicated clusters
+:learning-objective-3: Distinguish maintenance behavior for Serverless versus BYOC and Dedicated clusters
 
 As a fully-managed service, the Redpanda Cloud glossterm:control plane[] handles all maintenance operations, such as upgrades to your software and infrastructure. Here, _control plane_ refers to the Redpanda Cloud managed service that orchestrates cluster operations, not the Kubernetes control plane.
 
 For BYOC and Dedicated deployments, Redpanda manages all maintenance operations for the underlying infrastructure and Kubernetes, ensuring high availability. This includes Kubernetes version upgrades (both the Kubernetes control plane and worker nodes), security patches, and VM image updates. You do not need to act on Kubernetes end-of-life or deprecation notices from your cloud provider (for example, EKS, GKE, or AKS version warnings). Redpanda handles these upgrades on your behalf, targeting completion before the Kubernetes version reaches end of life.
 
+For Serverless deployments, Redpanda manages all maintenance centrally because Serverless clusters run on shared, multi-tenant infrastructure. You cannot configure a maintenance window or per-cluster schedule for a Serverless cluster. See <<serverless-maintenance,Serverless maintenance>>.
+
 Redpanda runs maintenance operations on clusters in a rolling fashion, accompanied by a series of health checks, so there is no disruption to the availability of your service. As part of the Kafka protocol, recycling nodes triggers client connections to be restarted. All mainstream client libraries support automatic reconnections when a restart occurs.
 
+After reading this page, you will be able to:
+
+* [ ] {learning-objective-1}
+* [ ] {learning-objective-2}
+* [ ] {learning-objective-3}
+
 == Maintenance windows
 
-Redpanda Cloud may run maintenance operations on any day, at any time. You can override this default and schedule a specific maintenance window on your cluster's *Dataplane settings* page. 
+Maintenance windows are available for BYOC and Dedicated clusters. 
+
+For BYOC and Dedicated clusters, Redpanda Cloud may run maintenance operations on any day, at any time. You can override this default and schedule a specific maintenance window on your cluster's *Dataplane settings* page.
 
 If you select a *Scheduled* maintenance window, then Redpanda Cloud runs operations on the day and time specified. Maintenance windows typically take six hours. All operations begin during your maintenance window, but some operations may complete after the window closes. All times are in Coordinated Universal Time (UTC).
 
 TIP: Redpanda Cloud maintenance cycles always start on Tuesdays. Clusters scheduled for maintenance on Tuesdays are updated first, and clusters scheduled on Mondays are updated last. Keep this in mind when sequencing updates for multiple clusters.
 
+[[serverless-maintenance]]
+== Serverless maintenance
+
+Serverless clusters run on shared, multi-tenant infrastructure, so Redpanda manages all maintenance centrally. You cannot configure a maintenance window, choose a maintenance day, or defer upgrades for an individual Serverless cluster. Redpanda may run maintenance operations on Serverless clusters at any time. Operations run in a rolling fashion across the underlying infrastructure and are designed to minimize workload impact. As with BYOC and Dedicated, all mainstream Kafka client libraries support automatic reconnections when a restart occurs.
+
+If you need control over when maintenance runs on your cluster, use a xref:get-started:cluster-types/create-dedicated-cloud-cluster.adoc[Dedicated] or xref:get-started:cluster-types/byoc/index.adoc[BYOC] cluster. Both support configurable maintenance windows.
+
 == Minor upgrades
 
 During your defined maintenance window, Redpanda Cloud runs minor upgrades. Minor upgrades include standard Redpanda state changes that clients handle gracefully, such as leader elections.