SLOs
Service level objectives per tier, how they are measured, error budgets and service credits.
Four objectives per tier: availability, start latency, execution integrity and metering accuracy.
Availability
Definition: the ratio of session creates that reach running within the provisioning deadline,
to session creates that should have succeeded.
Excluded from the denominator: creates refused for quota, spend cap, policy or residency — those are the system working correctly.
| Tier | Monthly target | Error budget |
|---|---|---|
| 0 | 99.95% | 21 min |
| 1 | 99.9% | 43 min |
| 2 | 99.9% | 43 min |
| 3 | 99.5% | 3 h 36 min |
| 4 | 99.5% | 3 h 36 min |
Tiers 3 and 4 carry lower targets because their dependencies are larger: a browser or a desktop VM has more that can fail to start than a gVisor sandbox, and the honest number is the one that can be held.
Running sessions are counted separately. A session that was running and failed for a platform
reason counts against availability for the duration it should have run.
Start latency
Definition: time from POST /sessions acceptance to state: running, measured server-side.
| Tier | p50 | p95 | p99 |
|---|---|---|---|
| 0 | 5 ms | 25 ms | 80 ms |
| 1 | 90 ms | 250 ms | 900 ms |
| 2 | 180 ms | 600 ms | 2.5 s |
| 3 | 1.2 s | 3 s | 9 s |
| 4 | 2.5 s | 6 s | 45 s |
The p99 column is the cold path. The objective is not that cold starts are fast — it is that they are rare, which is the warm-pool hit ratio target.
| Tier | Pool hit ratio target |
|---|---|
| 1 | > 98% |
| 2 | > 97% |
| 3 | > 95% |
| 4 | > 90%, or 100% for reserved depth |
Reserved pool depth is a contractual guarantee: within the reserved count, a claim always hits.
That is what the customer is paying pool_reservation_s for.
Execution integrity
Definition: the proportion of runs that complete without a platform-caused failure.
Target: 99.99% across all tiers.
Platform-caused: host failure, OOM from a platform misaccounting, guest kernel panic, runtime crash, network partition between gateway and node. Not platform-caused: the customer's command exiting non-zero, an egress denial, a timeout the customer configured, a guest OOM from the customer's own memory request.
This is the strictest objective in the list, deliberately. A session that starts fast and then silently loses work is worse than one that starts slowly.
Metering accuracy
Definition: the proportion of sampled sessions whose billed usage exactly matches the node's write-ahead log.
Target: 100%. Any mismatch is a billing incident at outage severity, not a budgeted error.
| Metric | Target |
|---|---|
| Reconciliation mismatches | 0 |
| Usage visible in the API | < 60 s p50, < 3 m p99 |
| Node WAL depth | < 1 h p99 |
Metering has no error budget because there is no acceptable rate of billing a customer incorrectly.
API availability
| Route class | Target | Measured |
|---|---|---|
| Control plane reads | 99.95% | Non-5xx ratio |
| Control plane writes | 99.9% | Non-5xx ratio |
| Session gateway (streams) | 99.95% | Successful connection establishment |
| Usage API | 99.5% | Non-5xx ratio |
Latency: gateway overhead p99 under 15 ms excluding the handler; placement decision p99 under 25 ms.
Measurement
All objectives are measured from platform telemetry, aggregated per region and per tier, over a
rolling 30-day window, and published on status.workspaces.build from the same metrics the infra
team runs on. There is no separate hand-maintained set of numbers.
| Principle | Consequence |
|---|---|
| Server-side measurement | Client network problems do not count against the platform, and are not hidden either |
| Per region and tier | A tier 4 problem in one region does not disappear into a global average |
| Rolling 30 days | No month-boundary reset that hides a bad week |
| Same source as alerting | The status page and the pager cannot disagree |
Error budget policy
Error budget burn drives engineering priority, not just reporting.
| Budget remaining | Policy |
|---|---|
| > 50% | Normal: ship features, routine maintenance proceeds |
| 25–50% | Caution: risky changes need a second reviewer; drains scheduled off-peak |
| 10–25% | Freeze: reliability work only for the affected tier and region |
| < 10% | Hard freeze: no changes to the affected path without an incident commander's approval |
The freeze applies per tier and per region, not globally. A tier 4 budget exhaustion in fra1 does
not stop tier 1 work in bom1.
Service credits
Applied automatically as a credit note on the next invoice. No claim is required — the platform knows which organizations were affected.
| Monthly availability, affected tier | Credit on that tier's charges |
|---|---|
| 99.0% – target | 10% |
| 95.0% – 99.0% | 25% |
| < 95.0% | 50% |
Credits apply only to the affected tier and region. Maximum credit in a month is 50% of that month's total charges.
Not credited: downtime caused by the customer's own configuration, quota or spend-cap refusals, announced maintenance drains, or force majeure.
What is not covered
| Why | |
|---|---|
| Run duration | Determined by the customer's workload |
| Egress throughput to third parties | Depends on the destination |
| Third-party MCP server availability | Not operated by the platform |
| Bot defences blocking tier 3 sessions | A property of the target site |
| Model behaviour | Not a platform component |
Reviewing
SLOs are reviewed quarterly. Targets move up when sustained performance exceeds them with budget to spare, and move down only with customer notice and a stated reason — a target nobody can hold is worse than an honest one.
The decision log records every change and its rationale.