Service Level Agreement
Network and Host-Node Uptime Guarantee
Last updated: October 27th, 2026
This Service Level Agreement (“SLA”) is part of our Terms of Service. It describes the availability we commit to, how we measure it, what we exclude, and the credits we pay when we miss.
1. What we guarantee
99.99% monthly availability of the network path and the host node that runs your service, measured per service item. Our target is 100%, which is why our plan pages say 100% — the guarantee we pay out against is 99.99%, and section 5 explains why that distinction is honest rather than a loophole.
This guarantee covers the two things we control completely: whether our network is reachable, and whether your host node is running. It applies per service item, not per invoice. If you have fifty servers with us and one is down, the credit is calculated on that one server, not your whole account.
What it does not cover: the availability of this website, our DNS service, our API, or your control panel. Those are separate systems and section 4 lists the exclusions in full.
2. Credits are applied automatically
You do not need to open a ticket, and you do not need to ask. When we record an eligible outage we:
- measure its start and end from our own monitoring, not from when someone noticed;
- calculate the credit from the table in section 3;
- apply it to your account automatically, and email you to say we did;
- post it within 30 days of the end of the incident, and show it in your portal under Billing, with the incident reference.
This is unusual — most hosts require you to notice the outage, open a ticket, and ask. We would rather pay what we owe than make you chase it.
If we miss one, tell us. If you believe an eligible outage was not credited, open a ticket or email support@lasthourhosting.org within 30 days of the incident with the approximate time and your service. We will review our monitoring data with you and, if the outage qualifies, credit it. This dispute window is a backstop, not the mechanism — the mechanism is automatic.
3. Credit table
| Downtime in the billing period, per service item | Credit (% of that item's monthly fee) | Credit in time |
|---|---|---|
| Less than 9 minutes | 2% | About 12 hours |
| 9 to 59 minutes | 4% | About 24 hours |
| 60 to 119 minutes | 8% | About 48 hours |
| 120 to 239 minutes | 20% | About 120 hours |
| 240 to 419 minutes | 40% | About 240 hours |
| 420 minutes or more | 100% | About one month |
We compute the row from the same probe history you can see in your portal: one minute of measured downtime is one minute on the ladder, and we take the row it falls in. There is no separate claim form, no threshold to argue about, and no rounding in our favour.
Credits are calculated against the monthly recurring fee of the affected service item, are capped at 100% of that fee for any single month, and are not combinable: one event produces one credit, even if it affects both network and host node.
Credits are applied to your account as credit, expire 12 months after issue, are not exchangeable for cash, and cannot be transferred. They are the exclusive remedy for a failure of this guarantee. Nothing in this section limits a right you have under consumer law that cannot be waived.
4. Exclusions
This guarantee does not apply to unavailability caused by:
- Scheduled maintenance announced at least 24 hours in advance and performed in our published window, which is 02:00–05:00 Pacific on the second Tuesday of each month.
- Emergency patching of a critical security vulnerability, provided the outage does not exceed 10 minutes.
- Software on your service — your operating system, your application, your plugins, your configuration, or a failed update you or we applied at your request.
- Your own actions — reboots, halts, shutdowns, firewall changes, resource exhaustion you caused, or a password you lost.
- Attacks aimed at your service where our mitigation did not prevent the impact. Network-level volumetric attacks that we fail to absorb within 15 minutes do count as an eligible outage; application-layer attacks that saturate your own application do not.
- Suspension for a breach of the AUP, a payment failure, or a legal requirement.
- Force majeure — the events listed in section 32 of the Terms of Service.
- Your upstream dependencies — your domain registrar, your DNS provider if it is not ours, your payment gateway, or your own internet connection.
- Beta or preview features, which are labelled as such and are excluded.
guarantee, and we would rather be believed than be broad.
A credit under section 3 is payable for any eligible outage, whether or not the monthly figure finished above or below 99.99%. We do not make you argue about whether a threshold was crossed.
5. How we measure
Availability is measured by our own monitoring, from at least two locations outside the affected node, at one-minute intervals, with a request that must complete successfully. An outage begins at the first failed check and ends at the first of two consecutive successful checks. We round to the nearest minute.
We publish a monthly uptime report per service item in your portal, and we keep the raw monitor data for 13 months so a dispute can be checked against it rather than argued about. If you want the raw data for your own service, ask and we will send it.
Why 99.99% and not 100%. No network can promise 100% with a straight face — a kernel panic, a fibre cut, or a routing bug can happen to anyone. 99.99% is about 4 minutes 22 seconds per month, which is demanding but real. We credit every minute of the difference, automatically. That is a better deal than a headline we would have to disclaim.
6. Packet loss and latency
We do not proactively monitor individual customer packet loss. We do monitor aggregate loss and latency across our network. If you report loss above 1% between your service and the first hop off our border router, or if we detect it ourselves, we will investigate and tell you what we find. Sustained loss above 1% attributable to our network is treated as an outage for the purposes of section 3.
7. Support response targets
Separate from uptime, these are our response targets. They are targets, not guarantees, and they are not credited:
| Severity | Example | First response target |
|---|---|---|
| Critical | Service down, or data at risk | 1 hour, 24/7 |
| High | Major function broken, workaround difficult | 4 business hours |
| Normal | One function broken, workaround exists | 1 business day |
| Low | Question, or a request for information | 2 business days |
Business hours are Monday to Friday, 08:00–17:00 Pacific, excluding US federal holidays. Critical issues are covered around the clock.
8. Changes to this SLA
We may change this SLA. We post the new version here, update the date, and email account holders at least 30 days before a change that reduces the guarantee or the credit table. A change never applies to a term you have already paid for.
9. Questions
Email support@lasthourhosting.org. If you want to discuss a credit or the measurement behind one, ask for the incident reference and we will send the monitor data.