TOOLNAVIA / 选购指南
ScalaHosting 可用性 SLA：99.99%承诺与99.9%补偿
先看结论
ScalaHosting Build #1 宣传 **99.99% 可用性**，但书面补偿表写的是：**99.9% 对应 0% 补偿，99.8% 对应 10%，计划维护不计入停机**。应为托管 VPS、支持和恢复流程买单，而不是把“四个九”直接理解成必然补偿。
页面当前显示的优惠路径为 $29.95/月，续费 $54.95/月。 本文含联盟链接；通过链接购买时，Toolnavia 可能获得佣金，但不会增加你的价格。
选购速览
- 适合谁
- 重视托管支持并能保存独立可用性证据的VPS买家。
- 收费方式
- 页面显示优惠$29.95/月；续费$54.95/月。
- 先看限制
- 产品页与补偿表门槛不同；计划维护被排除，申请仍需审核。
把服务目标与补偿规则分开读
产品页写着“99.99% uptime SLA”，条款补偿表却从 99.9%=0% 开始。ScalaHosting 的通用 FAQ、小企业页面与最新集群文章也把保证写成 99.9%。 独立评测同样指出了这一差异。
这不代表服务一定不可靠，而是说明**营销目标与合同救济没有清楚对齐，不能把 99.99% 当成确定的补偿触发线**。做购买决定时，应先按条款的保守口径预算和监控，除非 ScalaHosting 通过工单明确确认 Build #1 适用另一套规则。
把百分比换算成停机分钟
按 30 天计算，99.99% 约允许 4.3 分钟停机，99.9% 约允许 43.2 分钟，99.8% 约允许 86.4 分钟。这只是算术示例，不是对未来表现的预测。
按公开表格，99.9% 没有补偿。TechRadar 与 Scorura 也独立概括了同一阶梯和工单要求。 之后，99.8% 为 10%，99.7% 为 20%，之后每下降 0.1 个百分点，补偿增加 10%，低于 99% 时为 100%。 真正影响购买的问题不是“广告写了几个九”，而是“实测下降到什么水平才开始有救济”。
先理解哪些停机不计入
ScalaHosting 把计划维护排除在“真实停机”之外。 因此维护窗口即使影响应用，也未必支持 SLA 申请。条款还要求向账单部门开工单，并附上日志及其他相关细节；申请获批后，补偿在七天内计入账户。
页面使用了“refund”一词，但操作描述是把 credit 记入账户。在账单部门书面确认前，应把它理解为账户额度，而不是现金退款。还应询问发生争议时以平台监控还是客户日志为准；与 Kinsta 的同意图 SLA 相比，ScalaHosting 这一段的定义没有那么细。
在故障发生前建立证据包
上线前配置外部 HTTP 监控。保留 UTC 时间、受影响域名、响应码、截图或导出记录、故障开始和恢复时间，以及状态页或支持工单编号。把计划维护单独记录，避免把排除项混进可能合格的停机分钟。
故障结束后，根据可辩护的证据计算当月可用性，并尽快提交账单工单。引用的条款段落没有公布申请截止期，因此尽早提交更稳妥。这是工作流建议，不是对获批结果的保证。
比较 SLA 的清晰度，而不是短期评测成绩
短期测试只能说明某段观察期内是否在线，不能证明未来可用性，也不能替代合同。Cybernews 的短期结果很好，但仍把保证列为 99.9%；CloudsPress 也明确把少量可达性检查与长期 SLA 分开。
Kinsta 的官方 SLA 可作为“条款清晰度”参照：它定义了停机、维护期、月度订阅价值、补偿算法和 30 天申请期限。 这并不意味着 Kinsta 自动更适合，而是告诉 Build #1 买家在依赖标题前应向 ScalaHosting 问清哪些问题。
谁适合买 Build #1？
如果你需要托管云 VPS、专用资源、SPanel、异地备份和支持，并愿意自己做独立监控，Build #1 仍然适合。 可以把 99.99% 视为服务目标，但财务预期应以当前 99.9% 补偿表为准。
如果你必须获得合同明确的四个九救济、无法接受维护排除，或业务需要多节点高可用而非单台托管服务器，它就不那么合适。ScalaHosting 自己的集群文章也说明，突破单机上限需要集群架构。
购买前检查表
付款前保存当前套餐页和条款，并通过工单询问你的 Build #1 订单究竟适用哪个可用性门槛与补偿表。确认由哪套监控决定停机、哪些维护被排除、补偿是否只针对受影响服务，以及救济是账户额度还是现金。
如果这些答案符合你的风险预算，可以[查看已核实的 ScalaHosting Build #1 方案](https://www.scalahosting.com/#jbo732m8svf2o)。如果不符合，正确做法不是争论一个百分比，而是选择与停机成本匹配的架构和合同。
