Service levels
There is no service level agreement.
A control plane is deployed and it is invitation only, so there is nothing generally available to make an agreement about. Rather than leave a security review to discover that, this page says what is not committed, what holds anyway, and what would have to be true before a number here meant anything.
Not committed
None of this is promised.
- No uptime target, and no measured uptime to quote instead.
- No support response time, and no support tier to attach one to.
- No service credits, because there is nothing to credit against.
- No status page.
- No on-call rotation. An outage today reaches a person when a person happens to look.
True anyway
The part that survives our outage. The thing that gates your pull request does not run here.
| The verdict is local | The engine runs inside your own continuous integration and reaches a verdict there. No control plane is required to run it, and none is configured on most runs. |
|---|---|
| An outage cannot fail your build | Events buffer in memory, spill to a durable spool on disk, and are delivered by a later command. When the buffer is full the oldest events are dropped and the count is reported, because an environment must not stall because a dashboard is down. |
| Proven, not asserted | A chaos test runs a real command through the real orchestrator against a control plane that is genuinely unreachable, asserts the command did not fail, and asserts the control plane really did receive nothing. |
| Nothing phones home | There is no license server and no activation call. The enterprise edition reads a key from the environment. Nothing expires. |
What is deployed
A production control plane and a staging one, and only two people can sign in to either.
| Environment | Two: production at app.antifailure.dev and staging at app.dev.antifailure.dev, in separate resource groups, with separate databases and separate GitHub OAuth applications. Both are behind a sign-in allowlist naming the same two accounts. Production is reached only by promoting the exact image digest staging tested, behind an approval on a GitHub environment. |
|---|---|
| Redundancy | Production is configured for two application replicas and a zone-redundant database standby. Staging runs one replica and no high availability, deliberately, because a post-deploy health probe measuring a cold start measures nothing. The figures on this row are the ones the production stack declares, in infra/terraform/stacks/control-plane/production.tfvars. |
| Backups | Production is configured for thirty-five days of point-in-time recovery with geo-redundant backup storage, so a region losing its storage does not take the backups with it. Staging keeps fourteen days in one region with geo-redundancy off. A standby is not a backup: a bad migration reaches it instantly. |
| Monitoring | Metric alert rules and an action group are in the infrastructure and are enabled on production and off on staging, on purpose, because staging is meant to break several times a week and a page for that is a page somebody learns to ignore. Each rule's description carries the URL of its own runbook. Nobody is on call, so an alert reaches a mailbox rather than a person who is awake. |
| Recovery time | The restore drill now runs weekly against a real Postgres. It has reported under two seconds on a continuous integration runner and up to 160 seconds on a loaded laptop, and neither number is a recovery time objective: the only one that would mean anything is measured on the hardware you would actually recover onto. |
What has to be true before there is an SLA.
- A production environment, separate from staging, with its own credentials and its own sign-in application. In place.
- High availability on the database and more than one application replica. Configured on production.
- Geo-redundant backup, and a restore drill that runs on a schedule and fails loudly. Configured, and the drill runs weekly.
- Alerting that reaches a person, and a runbook per alert that the alert actually points at. The rules and the runbooks exist; who they reach is a mailbox, not a rotation.
- On-call, even if it is one person with a phone. Not yet.
- A status page, and enough measured history behind it for a number to mean something. Not yet: the probe runs, and its output is not published anywhere.
Drafted, not reviewed by counsel
An availability commitment is a contractual term, not a documentation change. This page describes the current state so that nobody has to infer it. It is not itself a commitment, and the wording of any future one needs counsel.
Next
Know what happens before you deploy.
Create a disposable production twin for every risky change. Catch migration failures before they reach customers.