SLA
This page is two things — the operational targets the platform runs against, and the contractual SLA that turns those targets into credit-bearing commitments on paid tiers. The engineering bar is the same on every tier; the legal commitment scales with the plan.
Operational targets
The targets below apply on every tier. Measured uptime is published on status.computesphere.com.
| Surface | Monthly target | Notes |
|---|---|---|
| Runtime — your deployed spherelets | 99.9% | When running 2+ spherelets. Single-spherelet services aren't covered (see honest limits). |
API — api.computesphere.com | 99.9% | Includes deploy/scale/configure operations. |
Console — console.computesphere.com | 99.9% | |
| Build system | 99.9% | Image builds and rollout orchestration. |
| Networking & TLS issuance | 99.95% | Inherited from the edge provider's published SLA. |
Coverage by tier
| Hobby | Pro | Team | Enterprise | |
|---|---|---|---|---|
| Operational targets above apply | ✓ | ✓ | ✓ | ✓ |
| Live status dashboard | ✓ | ✓ | ✓ | ✓ |
| Credit-bearing SLA | — | — | ✓ | ✓ (contract-defined) |
| Custom SLA terms | — | — | — | ✓ |
| Priority support during incidents | — | — | ✓ | ✓ |
| Dedicated account contact | — | — | — | ✓ |
Hobby and Pro accounts ride the same engineering bar — what you don't get is the contractual mechanism to claim credits when a target is missed.
What counts as downtime
| Counted | Not counted |
|---|---|
| HTTP 5xx responses confirmed to originate from the ComputeSphere layer (gateway, infrastructure) | Errors from your application code, container crash loops, non-zero exit codes |
| Inability of the platform to keep at least one healthy spherelet running when you have spare capacity | Errors caused by hitting your account's spherelet capacity |
| Failed deploys caused by a platform-side fault (build system / control plane) | Failed deploys caused by your code, your image, or your build configuration |
| Scheduled maintenance windows announced in advance via the status page (see Maintenance) | |
| Downstream services (your database, third-party APIs) being unavailable |
If you're not sure which side a given incident landed on, the status page is the source of truth — every confirmed platform-side incident shows up there.
Filing a credit claim — Team + Enterprise
- Wait for the calendar month to close. Monthly uptime is measured per-surface on monthly boundaries.
- Check the status page for that month — every confirmed platform-side incident is recorded there.
- If a covered surface fell below its threshold, email [email protected] within 30 days of the month's close with your account ID and the incident references.
- Approved credits apply to your next invoice. Credits are not paid as cash refunds.
- The maximum monthly credit is capped at the contractual percentage of that month's bill, per the terms in your signed contract.
Enterprise contracts can negotiate different thresholds, credit percentages, and exclusions — the contract supersedes anything on this page where they differ.
Honest limits
- Single-spherelet services aren't covered by the runtime target. Restarts during platform maintenance are expected on a single-spherelet service. Run 2+ to get the 99.9% target — see Reliability.
- Credit-bearing SLAs are a Team+ feature. On Hobby and Pro the targets are operational, not contractual. Plan accordingly if you need a contract document for procurement.
- No cross-region failover. Each environment runs in the one region you pick; a regional outage takes services in that region with it (see Architecture).
- Credits, not refunds. The remedy on a missed SLA is a credit against future invoices.
- Application-level errors aren't platform downtime. A bad deploy or a crash loop from your code isn't covered — that's by design. Use health checks and auto-scaling to absorb your own faults.
Questions
| Credit claims, SLA terms, Enterprise contracts | [email protected] |
| Live platform status | status.computesphere.com |
| Support during an active incident | support.computesphere.com |
What's next
- Reliability — the engineering behaviors behind these targets (zero-downtime deploys, health-checked rollouts, multi-spherelet HA).
- Maintenance — when scheduled windows happen and how they're announced.
- Architecture — the layers being measured.
- Status — how to subscribe to live updates.