Every level is a commitment you can hold us to, with service credits when the month falls short. In a 30-day month that is about 43 minutes of downtime at 99.9%, 22 minutes at 99.95%, and 4 minutes at 99.99%.

Standard and Advanced can be carried by any machines, one or many. Premium needs reserved cores on every machine carrying the site — the machines listed under Reserved CPU — and is sold with Advanced support or above.

Advanced is sold on a quarterly or yearly billing period, and Premium on a yearly one: a commitment measured in minutes is not one to take on a month at a time. A project on the shared plan carries Standard.

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.

Why Premium has conditions. On shared cores, another customer of the same provider can slow a site until our checks time out, with nothing failed on either side, and a site is only as available as its weakest machine. And a four-minute promise does not sit beside a four-hour, best-effort reply, so Premium is sold with Advanced or Premium support.

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.

The first row runs up to each level's own figure: 99.9% on Standard, 99.95% on Advanced, 99.99% on Premium.

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.

The paid levels credit more, not just sooner. They commit to a stricter figure and cost more, so missing it is worth more: the same month pays 15% on Premium where Advanced pays 10%, and 35% where Advanced pays 25%. Below 95%, both owe half the invoice; Standard, which is included, owes a fifth.

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, and 20% on Standard.

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 times are for urgent tickets: a site that is down. 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.

Premium support is sold on a quarterly or yearly billing period.

The Premium uptime SLA is sold with Advanced support or above.

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 were advised to add. When a machine’s CPU or memory stays above 90% for more than 30 minutes at a time, we tell you in writing and recommend the size that fits. If the recommendation is not taken up within 7 days, downtime that comes from that machine running out of CPU or memory does not count against availability, until it is resized or the load comes down. A site slow or refusing connections because it has outgrown its machine is not unavailable in the sense meant here — 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 any of our providers.

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.

A bare-metal server is one physical machine: a hardware fault is repaired by the provider, which can take hours. It is covered like any other failure, and it is one more reason a site that must not go down needs more than one machine.

Every level can be bought on any machines; the machines are ours to keep up, and a miss is ours to credit. But an SLA buys you a credit when the site fails, and 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.