DOC-2202: Document Serverless maintenance behavior#591
Conversation
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>
✅ Deploy Preview for rp-cloud ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR updates documentation to clarify how Serverless cluster maintenance differs from BYOC and Dedicated deployments. The changes add two layers of documentation: the main maintenance guide is updated to introduce Serverless-specific behavior (centralized management, no configurable maintenance windows, rolling upgrades with automatic client reconnection) and provide typical upgrade cadences (weekly cloud/control plane updates, ~three Redpanda version upgrades annually). The Serverless cluster-types reference page is augmented with a new "Maintenance and upgrades" section that explains these behaviors and links to the full maintenance policy. Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
modules/manage/pages/maintenance.adoc (1)
25-26: ⚡ Quick winSoften the “transparent” guarantee to avoid over-promising.
Given the later note about brief broker reconnections, “transparent” can read as absolute. Prefer “designed to minimize impact” (or similar) and mirror this wording in the Serverless cluster-types page for consistency.
Suggested wording diff
-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. Operations run in a rolling fashion across the underlying infrastructure and are designed to be transparent to your workload. As with BYOC and Dedicated, all mainstream Kafka client libraries support automatic reconnections when a restart occurs. +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. 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.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@modules/manage/pages/maintenance.adoc` around lines 25 - 26, Update the paragraph containing the sentence "Operations run in a rolling fashion across the underlying infrastructure and are designed to be transparent to your workload" to soften the guarantee: replace "designed to be transparent to your workload" with wording such as "designed to minimize impact to your workload" (or similar) and add a brief qualifier about brief broker reconnections; also make the same wording change in the Serverless cluster-types page so both pages mirror each other.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@modules/manage/pages/maintenance.adoc`:
- Around line 25-26: Update the paragraph containing the sentence "Operations
run in a rolling fashion across the underlying infrastructure and are designed
to be transparent to your workload" to soften the guarantee: replace "designed
to be transparent to your workload" with wording such as "designed to minimize
impact to your workload" (or similar) and add a brief qualifier about brief
broker reconnections; also make the same wording change in the Serverless
cluster-types page so both pages mirror each other.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b0f5b5c0-3a4b-4ff6-b602-416247efba41
📒 Files selected for processing (2)
modules/get-started/pages/cluster-types/serverless.adocmodules/manage/pages/maintenance.adoc
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>
micheleRP
force-pushed
the
DOC-2202-serverless-maintenance-windows
branch
from
6ff5de8 to
31cd1c1
Compare
| [[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. Maintenance operations run in a rolling fashion and are designed to be non-disruptive. Mainstream Kafka client libraries reconnect automatically when broker connections restart. |
There was a problem hiding this comment.
I think we should add that we run operations at any time and that is integral to making sure we keep up to date.
|
|
||
| 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. Maintenance 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. |
2 participants
Summary
Configurable maintenance windowsunder the existing Unsupported features list on the Serverless page.Closes DOC-2202.
Cadence figures match the language Support is already using with customers in #help-serverless threads. Phrased as "typical" so it's not read as a contractual SLA.
Preview pages
Test plan
npm run buildcompletes with no new warnings tied to the edited fileslocalhost:5002for both pages🤖 Generated with Claude Code