Availability and support

What the platform commits to, what it does not, and how to reach a person.

Written plainly, because a commitment you need a lawyer to read is not a commitment you can plan against.

What availability means here

Availability is measured per region and per service, not across your account as a whole. A region being healthy does not mean your application is healthy — an application that crashes on startup is unavailable, and that is not an outage of the platform.

The distinction matters because it decides who fixes what. If the platform is down, we fix it and you wait. If your application is down on a healthy platform, we will help you read the evidence, but the change has to be yours.

What is and is not covered

Covered. The platform cannot start, stop, deploy or route to your application. A managed database is unreachable while its region is healthy. The console or API is unavailable. Certificates fail to renew for a name that resolves correctly to us.

Not covered. Your own code. Your own dependencies and the services you call. Your domain expiring, or its records being changed or removed. Limits you set yourself, such as an address restriction or a rate limit. Capacity you did not buy — an application with one copy is unavailable while it restarts, by arithmetic rather than by fault.

Planned work

Planned work is announced before it happens. Where it can be done without interruption, it is. Where it cannot, the window is published in advance and kept as short as the work allows.

Two things reduce your exposure to it, and both are in your hands: run more than one copy of anything that matters, and choose an availability arrangement for your data rather than the cheapest one.

Getting help

Through the console is the fastest route and the one that carries context — the ticket knows which organization and which resource you are looking at.

By email for anything that does not fit a form, and for billing.

Urgently, when a production service is affected. Use this for "customers cannot reach us", not for "I have a question about pricing". Keeping the urgent channel urgent is what makes it work.

What to include

The list in When things go wrong is the same one our engineers use. The item most often missing is when it started, which is also the most useful: it is what lets us line your report up against what the platform was doing at that moment.

What to expect back

An acknowledgement that a person has it, an assessment of whether it is the platform or the application, and then either a fix or a clear statement of what you need to change. If it is ours, you will be told when it is fixed rather than being left to check.

If we get it wrong, say so in the same thread. A reopened ticket is cheaper for everyone than a new one that has lost the history.

Data you can take with you

Your data is yours and it leaves with you. Databases can be exported in a standard format; stores can be read with ordinary tools using credentials you already hold. There is no departure fee and no process to request it — the same mechanisms you use day to day are the ones that get your data out.

The same goes for private clusters: they are standard Docker Swarm or Kubernetes and keep running if you leave. See Private clusters without lock-in.

This is deliberate. A platform that is hard to leave is a platform that has stopped competing for you.

When the platform is at fault

If a covered service is unavailable beyond what was committed for it, the remedy is credit against the affected service. Ask for it in a ticket; it is not applied automatically, because we would rather a person confirmed what you were actually affected by than have an automated system guess and get it wrong in both directions.