The difference between a target and a commitment is the credit. 99.5% is what the platform runs to whether or not anybody has paid for a promise — saying so is more honest than implying an unpromised site is unmanaged. The paid levels raise the figure and make it something you can hold us to: Advanced commits to 99.8% and Premium to 99.95%, each with service credits when the month falls short. In a 30-day month that is about 1 hour 26 minutes of downtime at 99.8%, and 22 minutes at 99.95%.

The surcharge is a share of the machine cost rather than a flat fee, because what makes availability cost money is redundancy, monitoring and the credits owed when it is missed — and all three scale with what you run.

Availability means your production environment answers at its origin — the machine we run it on — with a status other than 5xx, measured from outside our network.

We check in layers. That the domain resolves; that it answers as your visitors reach it; and that the origin answers directly. The origin check goes around any CDN or proxy in front of your site to a health endpoint on the machine, which confirms the application stack is running and can reach its database.

The origin check decides. A domain served through a CDN, proxy or DNS provider you chose can fail for reasons on their side, and that is not an outage of ours. The domain checks are there so we can tell you where a failure was. Where the CDN in front of your site is ours, its failures are ours too.

From three places. We measure from three locations, run by three different providers on three continents, every 60 seconds — every 30 seconds on Premium. A minute counts as unavailable when at least two locations report a failure and none reports success. One location failing is a path problem on the internet rather than an outage of your site. A minute in which too few locations got an answer to decide either way is left out of the count.

Monthly Availability Rate is the share of measured minutes in a calendar month that were available, to two decimal places.

Measured per environment, never averaged across your account or across the platform. A figure averaged over every environment we run would hide the one customer who had six hours down, which is the only customer the number matters to.

Service credits, as a share of what was invoiced for the resources that missed.

Against the resources that failed, not the whole account. A database machine down for a day does not entitle anybody to a refund of the CDN commitment that served perfectly throughout. On a project running several machines this is the only version that stays fair.

Premium credits more, not just sooner. It commits to a stricter figure and costs twice Advanced’s surcharge, so missing it is worth more: the same month pays 15% where Advanced pays 10%, and 35% where Advanced pays 25%. The floor is shared — below 95% both owe half the invoice, because a month that bad is the same failure whatever was promised.

A month that lands exactly on a band boundary falls to the gentler band, so the answer does not depend on how many decimal places a monitor happens to report.

Credits are applied to your next invoice and are the sole remedy this agreement provides for unavailability. The maximum in any month is 50% of that month's charge for the affected resources.

We would rather you did not have to claim. Where our own monitoring shows an environment missed its commitment, we apply the credit without being asked and tell you we have done it. The process below exists for the cases we missed.

Write to us within 30 days of the end of the month in question, with the environment and domain, the dates and times you observed it down including timezone, and whatever evidence you have — your own monitoring, error pages, logs.

We answer within 10 working days with our own measurements, and we show you the data behind the answer whether or not it goes your way.

Separate from availability, bought separately, and not credited — but committed to at the paid levels.

Response means a person who has read the ticket and is working on it, not an automated acknowledgement. These are response targets; nobody can honestly guarantee a resolution time for a fault they have not seen yet.

These do not count against availability.

1. Announced maintenance, notified at least 72 hours in advance in a window we publish. We aim for under 4 hours a month and it is usually far less.
2. Emergency maintenance to close a security hole, where waiting would be worse than the interruption. Notified as soon as we can.
3. Your application. Code that errors, a migration that locks the database, a dependency that exhausts memory, a deploy that fails. We will help you fix it; it is not our outage.
4. What your deployments run. We switch to a new release without stopping the site. The steps your deployment runs after that — database updates, configuration imports, cache rebuilds, migrations — are your application's, and errors or downtime while they run do not count against availability. If a deployment needs the site offline, put it in maintenance mode yourself.
5. Your site switched offline. The time you have deliberately put it behind its offline page, from the console or the API. It is recorded and shown to you, and it is not an outage of ours.
6. Your configuration. DNS pointed elsewhere, a certificate you manage that expired, a firewall rule you set, a third-party API your site depends on.
7. Capacity you bought. A site slow or refusing connections because it has outgrown its plan is not unavailable in the sense meant here — though we will tell you, and help you size up.
8. Non-production environments. Staging and development environments share a machine, are restarted freely, and are sized for rehearsal. No commitment is offered on them at any level, and promising one would make them more expensive for a benefit nobody asked for.
9. Suspension under the Acceptable Use Policy or for non-payment.
10. Anything upstream we cannot route around — an internet exchange failing, a submarine cable, a DNS root problem, a national outage.
11. Force majeure: natural disaster, war, labour action, an act of a government.
12. Beta features, marked as such where you turn them on.

Note what is missing from that list: a provider's datacentre failing, a hypervisor crashing, a disk dying, a network partition inside Hetzner, UpCloud or Gcore.

We rent those machines. It would be normal in this industry to exclude their failures, and many platforms built the same way do exactly that — their terms disclaim the infrastructure underneath and pass the outage to you.

We do not, and it is a deliberate commercial position. We chose the providers, we chose the regions, and you contracted with us rather than with them. "Our upstream had an outage" is an explanation we will give you, and it is not an excuse that removes a credit.

What this means in practice: if you have bought an SLA and Hetzner loses a datacentre, you are owed a credit from us and we take that up with Hetzner ourselves.

A single-machine environment has a single point of failure in it by definition — that is what the plan is, and no SLA changes it. If an hour of downtime during a kernel upgrade is an incident rather than an inconvenience, you need more than one machine, and that is a plan decision rather than an SLA decision.

So Premium — 99.95%, twenty-two minutes a month — is sold only where at least two machines carry the site. One machine spends that on a single update, with nowhere to fail over to, and a promise that cannot be kept is only a credit waiting to be paid. The most a single machine is promised is Advanced. An SLA buys you a credit when the site fails; a multi-machine topology buys you it not failing. They are different purchases, and the second is usually the one people mean.

We give at least 30 days' notice by email before reducing any commitment in this document. Increases take effect immediately.