Service Level Agreement

Our monthly availability target, how we measure it and the service credits if we miss it.

Last updated

Effective date: October 4, 2026 · Version 1.3

In plain English

  • Our target is 99.9% availability per server in each calendar month, covering the host node your server runs on and our network.
  • We measure it per server, per calendar month, in UTC.
  • If we miss it, you receive a service credit of 10% to 100% of that server’s charges for the month, as account credit.
  • Claim within 30 days of the incident by opening a support ticket.
  • Scheduled maintenance announced at least 48 hours ahead, problems caused on your side, and attacks larger than our mitigation capacity do not count as downtime.

This summary is here to help you read the document. If it differs from the numbered sections, the numbered sections apply.

1. Scope

This Service Level Agreement (the “SLA”) is part of our Terms of Service. It applies to every virtual server in every location.

It covers the two components we operate:

  • the host node: the physical server and the virtualization layer your server runs on;
  • our network: everything from your server’s virtual network interface to the edge of our network, where we hand traffic over to upstream carriers and peers. Our network page describes it.

It does not cover the operating system and software inside your server, the Portal, the API, this website, support response times, or networks beyond our edge.

2. Availability target

We aim for 99.9% monthly availability for each server. In a 30-day month, that allows about 43 minutes of downtime.

3. How we measure availability

  • Downtime is a period in which, because of a failure of the host node or our network, your server is not running or cannot send or receive network traffic.
  • Downtime starts when our monitoring detects the failure or, if it does not detect it, when you report it in a ticket. It ends when service is restored. We count it in whole minutes; interruptions shorter than one minute are not counted.
  • Monthly availability = (minutes in the measurement period − minutes of downtime) ÷ minutes in the measurement period × 100.
  • The measurement period is the calendar month in UTC. For a server that existed only part of the month, it is the minutes the server existed in that month.
  • Degraded performance, such as packet loss or slow storage that does not stop your server, is not downtime under this SLA. Please still report it; we treat it as a fault.

4. Service credits

Monthly availability of the serverDowntime in a 30-day monthService credit
99.9% or moreup to 43 minutesnone
below 99.9%, down to 99.5%43 minutes to 3 hours 36 minutes10%
below 99.5%, down to 99.0%3 hours 36 minutes to 7 hours 12 minutes25%
below 99.0%, down to 95.0%7 hours 12 minutes to 36 hours50%
below 95.0%more than 36 hours100%
The credit is a percentage of the affected server’s charges for that calendar month. Downtime figures are for a 30-day month; longer and shorter months scale accordingly.
  • A server’s charges for the month are the hourly charges for that server in that calendar month, after the monthly cap described in our Terms of Service. The cap itself applies per billing period, which is one month from the date the server was ordered, not the calendar month, so one calendar month can include parts of two billing periods.
  • Credits are calculated to the cent and added to your account credit. For one server and one month, they never exceed 100% of that server’s charges for the month.

5. How to claim a credit

  1. Open a ticket in the Portal within 30 days after the end of the incident.
  2. Include the server’s name or ID and IP address, the start and end time of the outage in UTC as you observed it, a short description and any evidence you have, such as monitoring output or traceroutes.
  3. We review the claim and reply within 5 business days. If we confirm it, we add the credit to your account. If we decline it, we explain why.

Credits are not available for a period in which your account was suspended or in breach of the Terms.

6. Exclusions

Downtime does not include unavailability caused by:

  • scheduled maintenance announced at least 48 hours in advance (section 7);
  • you, or anyone using your account: your operating system, software or firewall configuration, reboots, reinstalls or resizes you start, resources exhausted inside your server, or work you asked us to do;
  • suspension or restriction under the Terms or the Acceptable Use Policy, for example for non-payment, abuse, a compromised server or a legal order;
  • denial-of-service attacks whose size or type exceeds our mitigation capacity, and the measures we take during an attack to protect our network and other customers, such as temporarily filtering or null-routing the attacked IP address;
  • failures outside our network, such as upstream carriers, internet exchanges, third-party DNS or your own internet connection;
  • events outside our control, as described in section 19 of the Terms;
  • features labeled beta or preview.

7. Maintenance

  • We announce scheduled maintenance at least 48 hours in advance by email to the address on your account, with the expected time window and impact. We schedule it outside the busiest hours of the location concerned where we can.
  • Emergency maintenance, for example to fix an urgent security issue or replace failing hardware, can happen with short or no notice. It counts as downtime unless another exclusion applies.

8. Limits

  • Service credits are your only remedy for a failure to meet the availability target, except where mandatory law gives you other rights.
  • Credits have no cash value, cannot be transferred and can be used only for our Services. Our Refund and Account Credit Policy explains how account credit works.
  • This SLA does not change the limitation of liability in section 17 of the Terms.

9. Incident information

We inform affected customers about significant incidents by email. On request, we provide a summary of an incident’s cause and of what we changed to prevent it from happening again. Ask through a ticket or at [email protected].

10. Changes to this SLA

We may update this SLA. A change that lowers the availability target or the credits takes effect no earlier than 30 days after we email you about it, and never in the middle of a calendar month. The version number and effective date are at the top of this page.