Status
status.computesphere.com is the single source of truth for platform health. It carries the live state of every customer-facing surface, scheduled maintenance windows, active incident updates, and post-incident reports.
If you only do one thing on this page: subscribe. Notifications fire only on real changes — new incident, status transition, resolution — so the channel stays quiet when the platform is.
Subscribe — pick the channel that fits
| Channel | Best for |
|---|---|
| Engineering broadcast lists, on-call rotation accounts. | |
| SMS | Pager-style escalation when something is on fire. |
| Slack | A #platform-status channel in your workspace. |
| RSS | Aggregators, dashboards, status-page mirrors. |
| Webhook | Custom routing into PagerDuty / Opsgenie / your incident tooling. |
Sign up directly on status.computesphere.com. Notifications fire only on changes — not on every health check.
What's monitored
| Surface | What it covers |
|---|---|
| API | REST endpoints at api.computesphere.com. |
| Console | The web console at console.computesphere.com. |
| Build system | Source-to-image builds for services connected to a Git repo. |
| Runtime | Customer service availability — your deployed spherelets. |
| Networking | Edge routing, custom domains, TLS issuance. |
| Observability | Metrics, logs, and dashboards. |
Each surface is reported per region, so you can tell at a glance whether an issue is global or scoped to one region.
Incident lifecycle
Every incident moves through the same status transitions on the page. Subscribers get a notification on each one.
| Status | What it means |
|---|---|
| Investigating | We've seen something off. Cause not yet confirmed. |
| Identified | Root cause located. Working on the fix. |
| Monitoring | Fix deployed. Watching the recovery curve before declaring resolved. |
| Resolved | Surface is back to normal. A post-incident report follows. |
During an active incident the platform team defaults to over-communicating — a short update at least every 30 minutes, even if there's nothing new, so you're never wondering whether anyone is looking.
During an incident
- Check the status page first. If we're aware, there's a banner with the active incident.
- Subscribe to updates on that specific incident. You'll get a notification on every status transition.
- Open a support ticket if your service is affected and you don't see a matching incident on the status page. That's the signal the team uses to escalate.
After an incident
Every resolved incident gets a post-incident report on the status page within five business days of resolution. Each report covers:
- What happened — timeline, scope, and the customer-visible impact.
- What we did to resolve it — the actions taken in the moment.
- What we're doing to prevent recurrence — the durable fix, plus the follow-up work that wasn't completed in the incident itself.
Your own early-warning signals
Independent of the status page, two of your service's own metrics are useful early-warning signals — sometimes you'll see something before the platform-wide status flips:
| Metric | Why it's a leading indicator |
|---|---|
| 5xx rate on your service | A sudden bump above your baseline often precedes a platform-side status flip by minutes. |
| Build duration | Sudden spikes can indicate platform-side build-agent contention before it shows up on the Build surface. |
Both live in the console under your service's Metrics tab. For alerting on either, see Alerts.
Honest limits
- Status is platform-wide, not per-service. If your specific service is degraded but the platform surfaces are green on the status page, file a support ticket — the platform team uses that as the signal to dig.
- Post-incident reports are five business days. Real-time updates ship during the incident, but the formal report follows after.
- The status page isn't an SLA credit claim form. Credit-bearing claims go through [email protected] per the SLA page.
- Subscription channels are fanout-only. You can't filter to just one surface from the status page — most aggregators (PagerDuty, Slack) can do that filtering on their side.
- The platform doesn't push to your own services. A status update isn't broadcast inside your environment — bring your own consumer (webhook or RSS poller) if you want a programmatic signal.
What's next
- Reliability — the engineering behaviors behind a green status page.
- Maintenance — scheduled windows and how they're announced.
- SLA — operational targets and credit-bearing commitments.
- Alerts — wire your own thresholds on top of your service's signals.