> Canonical: https://antifailure.dev/sla > There is no service level agreement. What is not committed, what holds anyway, and what would have to change. # 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. ## 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. ## 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. | ## 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. - Terms of Use The promise is evidence, not zero-failure. Read - Data Processing Agreement The security measures that do and do not exist. Read - Pricing Community, team, and enterprise. Read ## Know what happens before you deploy. Create a disposable production twin for every risky change. Catch migration failures before they reach customers.