Service Level Expectations
Effective June 12, 2026 · Last updated June 12, 2026
Beta caveat: we publish this as a transparency document, not a financial commitment. Service credits start accruing at General Availability (GA), expected 2026 Q3+. Current uptime is at
/status.
This page describes the uptime we aim for, how we measure it, and how service credits work once we exit beta. During beta no service credits accrue; we publish this as a transparency commitment so you can see the metrics we hold ourselves to.
1. What we measure
| Surface | Target | Beta status |
|---|
Agent control-plane API (/api/v1/*, /api/agent/*, /mcp) | 99.5% monthly | Transparency-only; no credits during beta |
| Stripe webhook + checkout endpoints | 99.5% monthly | Transparency-only |
| Customer container runtime (tenant pods) | 99.5% monthly per container, excluding planned maintenance | Transparency-only |
| Status page itself | 99.9% | Always |
2. How we measure
- External synthetic probes hit the control-plane API every 60 seconds from at least two geographic locations
- "Downtime" = a sustained period (≥2 consecutive failed probes, ≥3 minutes) of HTTP 5xx, timeouts, or DNS failures from those probes
- Tenant container uptime is measured by the same K8s readiness probes that gate traffic
- Monthly uptime = (total minutes − downtime minutes) ÷ total minutes
3. What\'s excluded
- Planned maintenance announced at /status at least 24 hours in advance, typically scheduled for low-traffic windows
- Force-majeure events: natural disasters, regional ISP outages, DDoS attacks of unprecedented scale, government actions, internet backbone failures, sub-processor outages beyond our control
- Issues caused by customer code (a tenant app crash-looping is the tenant\'s issue, not platform downtime)
- Issues caused by misuse or AUP violations
- Beta-phase incidents during the beta window
4. Service credits (post-GA)
Once we exit beta and publish a binding SLA, service credits will work like this (subject to revision in the binding SLA):
| Monthly uptime | Credit |
|---|
| 99.5% – 100% | None |
| 99.0% – 99.49% | 10% of that month\'s subscription |
| 95.0% – 98.99% | 25% of that month\'s subscription |
| Below 95.0% | 50% of that month\'s subscription |
Credits are issued as future-billing-period discounts. To request a credit, email [email protected] within 30 days of the affected month with the incident reference from /status.
5. Status communication
- /status — live current state, recent incident timeline, planned maintenance windows
- Email — broadcast incident announcements for incidents affecting >5% of accounts
- The MCP
initialize handshake surfaces platform-wide incidents in _metadata.attention_items so your AI agent sees them immediately
6. Incident response
On a confirmed platform incident we commit to:
- Acknowledge on the status page within 15 minutes
- Initial diagnostic update within 60 minutes
- Updates at least every 90 minutes until resolved
- Post-incident review published within 5 business days for any P0/P1 incident lasting >30 minutes
7. Beta caveat
During the beta window, the targets above are aspirational. We track them publicly and post-mortem incidents so you can see how we\'re tracking against the post-GA commitments. We do not issue service credits during the beta window. We will give at least 30 days\' email notice before the binding SLA takes effect.