1. What is covered#
1.1 This agreement covers on-demand instances and reserved capacity instances.
1.2 It does not cover spot instances. Spot capacity is interruptible by design: we may reclaim it after a 2-minute notice, and doing so is never a failure of this agreement. If you need an availability commitment, run on-demand or reserve capacity.
1.3 It does not cover persistent volumes as a storage service, the website, the console or the API. Those are operated with the same care, but the commitment here is about instance availability.
2. What “unavailable” means#
2.1 An instance is unavailable during any period of five consecutive minutes or more in which it is not reachable on its network interface, or in which its GPU is not usable, for a reason within our control.
2.2 Unavailability is measured in whole minutes, per instance, from the first minute of the qualifying period to the minute the instance is reachable again.
2.3 An instance that is stopped, terminated, suspended for non-payment or suspended under the acceptable use policy is not unavailable — it is stopped.
3. The target#
3.1 Monthly Uptime Percentage = (total minutes in the calendar month, minus unavailable minutes) ÷ (total minutes in the month) × 100, calculated per instance.
3.2 Our target is 99.9% Monthly Uptime Percentage for each covered instance.
3.3 For an instance that existed for only part of the month, the calculation uses the minutes during which it existed and was not stopped by you.
4. Service credits#
If the Monthly Uptime Percentage of a covered instance falls below the target, you can claim a credit calculated on what you paid for that instance in that month:
| Monthly Uptime Percentage | Credit on that instance's monthly charges |
|---|---|
| Below 99.9% and at or above 99.0% | 10% |
| Below 99.0% and at or above 95.0% | 25% |
| Below 95.0% and at or above 0% | 50% |
Credits are added to your prepaid balance. They are not paid in cash and do not extend the term of a reservation.
5. Exclusions#
Time does not count as unavailable when it results from:
- Your own software, image, configuration, keys, firewall rules or code inside the instance.
- A stop, termination or restart initiated by you or by your automation, including through the API.
- Suspension for non-payment, or for a breach of the acceptable use policy.
- Planned maintenance announced at least 48 hours in advance, up to four hours per calendar month.
- Emergency maintenance needed to protect the platform, its customers or its hardware.
- A reclaim of a spot instance after a valid notice.
- Failures of networks, devices or providers outside our control, between our edge and you.
- Force majeure: events beyond reasonable control, including power and connectivity failures at a facility that persist despite its own redundancy.
6. Claiming a credit#
6.1 Open a ticket in the console within 30 days of the end of the month concerned, with the subject SLA claim.
6.2 Include the instance references, the dates and times in UTC of each period you consider unavailable, and any evidence you have — monitoring output, logs, request traces.
6.3 We compare that against our own records and answer within ten working days. Where our records confirm the outage, the credit is applied without argument. Where they do not, we show you what we see.
7. Maintenance#
7.1 Planned maintenance that can affect running instances is announced by email to affected account holders and on the status page, at least 48 hours in advance.
7.2 Most platform work — catalogue, pricing, console — does not touch running instances and is not announced as maintenance. It appears in the changelog.
8. Sole remedy#
Service credits are the only remedy for unavailability of covered instances. The limits of liability in the terms of service apply to everything else.