Service level agreement

Commitments are measured per calendar month, per service, and per account. A bad month on email does not dilute a perfect month on hosting.

By a third-party monitoring provider from three independent locations on different networks, at 30-second intervals. An outage starts at the first failed check confirmed by a second location, and ends at the first successful check. We use the external record, not our internal monitoring, because grading your own homework is how this industry got its reputation.

• Downtime is counted in whole minutes and rounded up.
• Two locations must agree before a check counts as a failure, so a single monitoring node's bad day is not your outage.
• The raw check history for your services is visible in the control panel and exportable as CSV.
• Partial degradation — served but slower than 3× your 30-day median response time — counts as downtime at 50% weight.

Credits are calculated from the affected service's monthly fee — for annual and triennial terms, the term price divided by the number of months. They are applied to your next invoice automatically within five business days of month end, with the calculation shown.

• No claim form. No 30-day claim window that you were supposed to know about. No requirement to have noticed.
• Credits are capped at 100% of the affected service's monthly fee, and are the exclusive contractual remedy for downtime.
• If a single incident takes you below 95% we will also write to you personally with the post-mortem, before it is published.
• Credits never expire and are paid out in cash on request if you are cancelling.

S1 escalation pages a senior engineer directly and is available on Scale, Cloud VPS, dedicated and reseller plans. Every severity is answered by an engineer with shell access; there is no tier one and no premium support product to buy.

Most maintenance is invisible: we live-migrate workloads rather than taking them down. When downtime is genuinely unavoidable, we announce it at least 7 days ahead by email and on the status page, and we schedule it in your region's lowest-traffic window.

These do not count as downtime. The list is deliberately short — every additional exclusion is a way of not paying, and we would rather have fewer of them.

• Faults in your own code, database queries, plugins or themes, including an application that cannot cope with its own traffic.
• Exhausting a resource limit published on your plan page, where we had already written to you about it.
• Suspension for non-payment after two notices, or for an AUP violation upheld on appeal.
• Downtime caused by something you asked us to do, or by a change you made in the panel or over SSH.
• Failure of a domain you manage elsewhere — an expired registration or DNS hosted with a third party.
• Genuine force majeure: war, natural disaster, or a nationwide carrier failure affecting multiple providers. Our own hardware failing is not force majeure.

Any incident affecting more than one customer is published on the status page within ten minutes — before we know the cause, which means the first note usually says so. A written post-mortem follows within 72 hours and stays online permanently.

• Post-mortems name the cause honestly, including when the cause was one of our own engineers pushing a bad change on a Friday.
• They list the specific remediation work with owners and dates, and we mark each item done in public.
• We do not quietly delete old incidents to improve the look of the page.

We will not reduce a commitment or add an exclusion during a term you have already paid for. Changes that improve the SLA take effect immediately. Changes that reduce it apply only from your next renewal, are emailed 30 days ahead, and entitle you to terminate with a prorated refund if you would rather not accept them.