Skip to main content
Service Level Objectives (SLOs) are the reliability commitments we make to ourselves and to customers. This page defines the SLIs we measure (the indicators), the SLOs we aim for (the targets), and the error budgets that drive deploy decisions. The numbers below are starting points. As we accumulate production data, they’ll firm up — what’s “achievable but not free” today may become “easy” or “impossible” tomorrow.

​
SLIs (what we measure)

​
Availability

Excludes:
  • 4xx (caller errors).
  • 503 from migration-required (operational, not failure).
A 5xx is anything between 500 and 599. Streamed error events count as 5xx for this purpose if the agent never sent a thread_lifecycle: completed.

​
Latency (request)

Time-to-first-token (TTFT). The user’s perception of “the agent is working” starts here.

​
Latency (turn)

Total turn time. Some turns are legitimately long (multi-step coding sessions); the p99 is the right tail to watch.

​
Cost

Soft target — informational, not a deploy gate. But P99 spikes are worth investigating.

​
Cache hit ratio

A drop in cache hit ratio is a leading indicator of cost spikes and behavioral drift.

​
SLOs (what we commit to)

Per-month windows. 99.5% over a 30-day window allows ~3.6 hours of downtime. This is the right starting target — we’re not running 24/7 tier-1 support yet. When we onboard production customers with stricter SLAs, the target moves to 99.9% (which allows ~43 minutes/month).

​
Error budgets

The error budget is the difference between 100% and the SLO target. When the error budget is healthy:
  • Deploy freely.
  • Take risks on infrastructure changes.
  • Run experimental Engines in parallel.
When the error budget is < 50% used:
  • Slow down deploys; require canary.
  • Defer non-critical infrastructure work.
  • Investigate what’s burning the budget.
When the error budget is exhausted:
  • Stop non-critical deploys.
  • All hands on reliability.
  • Cool-down period until the next monthly window.
This is a self-imposed gate. It’s not magic; it’s discipline.

​
Burn-rate alerts

The error budget burns at a rate dependent on how bad the failures are. We alert on burn rate, not just absolute error rate, because a 2% error rate sustained for an hour burns budget at a different rate than 100% for a minute. A “1× normal” burn rate is the rate at which the budget would deplete exactly at the end of the month if it continued.

​
Per-customer SLOs

For deployments with multiple customers, per-customer SLOs may apply above the global ones. A specific customer might have:
  • Tighter availability (99.9%).
  • Tighter latency (TTFT < 3s p99).
  • Reserved capacity (their Engine never shares resources).
These are negotiated separately and tracked in the customer’s contract; they live in their own dashboards.

​
Scope

These SLOs cover the Engine itself. They do not cover:
  • LLM provider availability. We can’t promise what we don’t control.
  • MCP server availability. Each connector has its own SLO with its own provider.
  • Network availability between customer and Engine. That’s the customer’s network and ours, jointly.
For customer-facing SLAs, factor in upstream dependencies and appropriate cushions.

​
Reporting

Per-month SLO compliance is reported in the engineering review:
Misses don’t trigger panic; they trigger investigation. The pattern matters more than any one month.

​
See also