Define your SLA precisely. What is committed, what is measured, what do I get when you miss, and how would I even know you missed?

The full executive answer

I will give you the unusually precise version, because we wrote it into the product. The commitment: a 99.5% monthly availability objective for the web application and public API, excluding scheduled maintenance announced on the status page at least forty-eight hours ahead. Recovery targets: RTO of four hours or less, RPO of twenty-four hours or less. Support: standard tier gets first response within one business day; founding and enterprise tiers get a named contact and four business hours. Contractual service credits for enterprise agreements are defined in the order form.

Now the part almost no vendor volunteers: what is measured versus what is a target. Internally we hold a stricter 99.9% availability objective as our engineering SLO — but our own code marks it, literally with a flag in the source, as a target, not a measured number, because the external probe history is not yet accumulated. Today, AI-generation latency is the objective we measure live from our gateway ledger. Our SLA page says this in plain language: commitments as commitments, targets as targets, measured numbers only where we actually measure. We refuse to claim a historical uptime percentage we have not earned the history to prove.

How would you know we missed? The public status page reports seven subsystems with incident history, incidents run a disclosed lifecycle ending in a post-review, and as external probing comes online the measured availability publishes there continuously. So the enforcement mechanism is contractual credits for enterprise, and the detection mechanism is public, not something you have to take on faith.