If we go down, your applications do not.

What an outage actually costs you

Deployments run as pipelines against infrastructure you own. Once something is deployed, it runs there, answering its own traffic, with no dependency on us.

So if the control plane is unavailable, what stops is your ability to change things — not your ability to serve users.

We intend to say this plainly rather than bury it. It is the honest description, and it happens also to be the favourable one: an outage here delays a deployment, it does not take a production system offline.

What we intend to commit to

• An availability target for the control plane itself — the portal, the API, and the ability to submit deployments.
• Service credits scoped to that platform availability, proportionate to an interruption in making changes.
• No commitment covering the uptime of your own applications, or of the cloud and hypervisor providers underneath them. Those are outside our control and would be dishonest to promise.

Where a deployment can be delayed by others

A deployment passes through systems we do not operate: your infrastructure provider, and the pipeline platform that runs the jobs. A failure in either can stall a deployment while the control plane itself is perfectly healthy. Any measured target has to account for that boundary, so the numbers describe something we can actually influence.

Still to be settled

The availability percentage, measurement window, credit schedule, support response times per plan, and the status and incident communication process are not yet fixed. They will be set once the platform has enough operating history for a target to mean something, rather than being picked because the number looks reassuring.