Maintenance
ComputeSphere upgrades the platform — operating system layer, gateway, observability, control plane — on a continuous cadence. Most of it, you don't notice. Service-affecting windows are scheduled and announced; everything else rolls behind the scenes.
What gets upgraded — and what you see
| Layer | How it rolls | What you see |
|---|---|---|
| OS / runtime under your spherelets | One spherelet at a time, same zero-downtime rollout used for your deploys. | Nothing — if you run 2+ spherelets. Brief restart window on single-spherelet services. |
| ComputeSphere gateway + edge | New gateway pods take traffic only after passing internal health checks; old ones drain. | Nothing. |
| Platform observability (metrics, logs) | Independent of the data plane. Rolls during normal hours. | Logs and metrics may briefly lag or pause. Your service keeps serving. |
| Control plane (API, console, build system) | Independent of the data plane. Rolls anytime. | You may not be able to deploy or change services for a few minutes. Running services keep running. |
The same rollout mechanic that ships your code is what ships ours — see Reliability for the per-spherelet detail.
Scheduled vs continuous
| Scheduled windows | Continuous updates | |
|---|---|---|
| What | OS/runtime upgrades, edge changes, gateway version bumps. | Security patches, control-plane releases, observability tuning. |
| Cadence | Quarterly, on average. | Daily. |
| Notice | Email to account owners + status page banner, days in advance. | None — they're designed to be transparent. |
| Single-spherelet impact | Brief restart window. | None. |
Heads up — single-spherelet services
A service running on a single spherelet is a single point of failure. During an OS/runtime window that rolls your spherelet, you'll see a brief restart blip — typically seconds, but it counts as observable downtime to your users.
To eliminate that: run two or more spherelets. Maintenance rolls one at a time and the other carries traffic. The pricing implication is real (you pay for 2× spherelets instead of 1×); the availability benefit is concrete.
For most production traffic this is the single biggest reliability lever available — see Reliability.
How you're notified
| Channel | What you get |
|---|---|
| status.computesphere.com | Advance notice for scheduled windows + real-time updates during any incident. Subscribe via email, RSS, Slack, or webhook. |
| Heads-up to account owners before a scheduled service-affecting window. | |
| Console banner | In-product banner appears for the duration of an active window. |
Subscribe to the status page so you don't have to remember to check.
If you see issues afterward
- Check the status page for "all clear" — sometimes a window closes for one layer while another is still rolling.
- If something specific to your service looks off, redeploy (push a new commit, or click Redeploy in the console). The new spherelets boot on the fresh platform layer.
- Open a support ticket if your service is still degraded.
Honest limits
- No customer-scheduled windows. You can't pin a maintenance time to your off-hours; scheduled windows roll for the whole region.
- No opt-out. Skipping a platform upgrade isn't an option — security patches and runtime upgrades apply to every service in the region.
- Single-spherelet services aren't shielded. No amount of platform sophistication eliminates a restart window for a service with one spherelet. Add a second one.
- Control-plane downtime ≠ data-plane downtime. A control-plane maintenance window stops you from deploying, but services keep serving. Track them as separate components on the status page.
What's next
- Reliability — the rollout mechanic the platform uses on itself, and what you opt into to ride through it cleanly.
- SLA — what the maintenance practice above translates into as an operational target.
- Status — how to subscribe to the live dashboard.