TOOLNAVIA / BUYING GUIDE
ScalaHosting Uptime SLA: 99.99% Promise, 99.9% Credit
The short answer
ScalaHosting Build #1 advertises **99.99% uptime**, but its written credit table says **99.9% earns 0% credit, 99.8% earns 10%, and scheduled downtime does not count**. Buy it for the managed VPS, support and recovery workflow—not because four nines automatically means compensation.
The page currently shows $29.95/month on the observed introductory path and $54.95/month at renewal. This article contains affiliate links; Toolnavia may earn a commission at no additional cost to you.
At a glance
- Best for
- Managed-VPS buyers who value support and can keep independent uptime evidence.
- Price model
- Displayed $29.95/mo intro path; $54.95/mo renewal.
- Check first
- The product page and credit table use different thresholds; scheduled downtime is excluded and claims require approval.
Read the promise and the remedy separately
The product page says “99.99% uptime SLA,” while the terms table begins at 99.9% with zero credit. ScalaHosting's general FAQ, small-business page and current cluster article also describe the guarantee as 99.9%. An independent review noticed the same mismatch.
That does not prove the service will be unreliable. It means the **marketing target and the contractual remedy are not aligned clearly enough to treat 99.99% as a guaranteed credit threshold**. For a purchase decision, the conservative rule is simple: budget and monitor against the terms until ScalaHosting confirms in writing that Build #1 receives a different remedy.
Convert the percentages into downtime
In a 30-day month, 99.99% uptime allows roughly 4.3 minutes of downtime; 99.9% allows roughly 43.2 minutes; 99.8% allows roughly 86.4 minutes. These are arithmetic illustrations, not forecasts.
Under the published table, a month at 99.9% receives no credit. TechRadar and Scorura independently summarize the same graduated ladder and ticket requirement. A result of 99.8% maps to a 10% credit, 99.7% to 20%, and the table continues in ten-point credit steps until uptime below 99% maps to 100%. The meaningful buyer question is therefore not “How many nines are advertised?” but “At what measured level does a remedy begin?”
Know what the credit excludes
ScalaHosting excludes scheduled downtime from “real downtime.” That exclusion matters because a maintenance window may interrupt your application without helping an SLA claim. The terms also require you to open a billing ticket and include logs plus other relevant details. Approved credit is applied to the account within seven days.
The page uses the word “refund,” but the operational text describes a credit applied to the account. Treat it as an account remedy rather than cash until billing confirms otherwise. Also ask whether provider-side monitoring or your logs control a disagreement; the published ScalaHosting section does not define that as precisely as Kinsta's same-intent SLA does.
Build a claim file before an outage
Set up an external HTTP monitor before launch. Keep timestamps in UTC, the affected hostname, response code, screenshots or exports, incident start and recovery time, and any provider status or ticket reference. Record planned maintenance separately so you do not mix excluded and potentially eligible minutes.
When an incident ends, calculate monthly availability from the evidence you can defend, then open the billing ticket promptly. ScalaHosting does not publish a claim deadline in the cited uptime section, so prompt filing is safer than waiting. This is a workflow recommendation, not a promise that a claim will be approved.
Compare SLA clarity, not review uptime
Short review tests can show that a host was reachable during a test window, but they cannot prove future uptime or replace contract terms. Cybernews reported a strong short test while still listing the guarantee as 99.9%; CloudsPress likewise separates a small reachability sample from the SLA.
Kinsta's official SLA is useful as a clarity benchmark: it defines downtime, maintenance periods, monthly subscription value, how credits are calculated, and a 30-day request deadline. That does not make Kinsta the automatic choice. It shows which questions a Build #1 buyer should ask ScalaHosting before relying on the headline.
Who should buy Build #1?
Build #1 fits buyers who want a managed cloud VPS, dedicated resources, SPanel, offsite backups and support, and who can operate their own independent monitoring. The 99.99% headline can be viewed as a service target, but the current 99.9% credit table should govern financial expectations.
It is a weaker fit if a contractually explicit four-nines remedy is essential, if maintenance exclusions create unacceptable risk, or if your application requires multi-node high availability rather than one managed server. ScalaHosting's own cluster article explains that clusters are the route beyond a single-machine ceiling.
Purchase checklist
Before paying, save the current plan page and terms, ask support which uptime threshold and credit table apply to your exact Build #1 order, and request the answer in the ticket. Confirm what monitoring source decides uptime, which maintenance events are excluded, whether credit is limited to the affected service, and whether the remedy is account credit or cash.
If those answers fit your risk budget, [review the approved ScalaHosting Build #1 offer](https://www.scalahosting.com/#jbo732m8svf2o). If they do not, the correct decision is not to argue about a percentage—it is to choose an architecture and contract with a remedy that matches your downtime cost.
