新上线的 SLA Credit Watch 会持续读取 AWS、Cloudflare、Google Cloud、Microsoft 365、Azure、Slack、Twilio 和 Zoom 的状态页面，按月累计服务中断时间，并在达到 SLA 赔偿门槛时提示可以申请多少服务额度以及截止日期。

一句话结论：云厂商的 SLA 通常不是自动赔钱，用户必须自己证明受影响、按时申请；很多本来可以拿回的额度，就这样静悄悄过期了。

SLA 很容易被误解成“可用性低于承诺，系统自动退款”。实际合同往往要求客户在限定时间内提交工单，列出账号、受影响服务、地区和中断时间。即使申请成功，得到的通常也是未来账单可用的 service credit，而不是现金，也不补偿业务损失。

AWS Compute SLA就是典型例子：只有符合指定月度可用率和服务范围的事件才可能产生额度，申请还要经过 AWS 确认。状态页显示红色，并不自动证明你的具体实例满足赔偿条件；反过来，状态页没有及时确认，也不代表你一定没有受到影响。

SLA Credit Watch 解决的是信息整理，不是替用户完成索赔。它目前展示状态页事件和理论门槛，但每家厂商的合同算法、排除条款、区域划分和申请材料都不同。工具如果只按公开状态页计算，可能漏掉局部故障，也可能把不在 SLA 范围内的事件算进去。

它真正有价值的地方，是把 SLA 从采购文档里的一行承诺，变成运维和 FinOps 可以执行的流程：自动记录事件、关联自己的监控证据、计算影响窗口、在截止前生成申请材料。对于云支出较大的团队，哪怕一年只成功申请几次，也可能覆盖工具成本。

举个更具体的例子：某服务承诺月可用率 99.9%，不等于当月故障 44 分钟就能获得业务损失赔偿。合同可能按单一区域、单项服务或单个实例计算，还会排除计划维护、用户配置错误和不可抗力。达到某一档后，赔偿也许只是该服务当月费用的 10%，并且只能抵扣未来账单。

因此，企业内部至少要保存四类证据：自己的探测数据、云厂商事件编号、受影响资源清单和用户可见影响。状态页截图只能说明厂商承认过某种异常，无法说明你的资源在多长时间里不可用。最理想的自动化不是“看到红灯就算钱”，而是把厂商事件与自己的监控时间线自动对齐，再由人核对合同例外。

关键事实

• 工具跟踪八家主流云与 SaaS 厂商的公开状态页面。
• 达到门槛后，它会提示服务额度计算和申请截止日期。
• 厂商 SLA 通常要求客户主动提交申请，不会自动退款。
• 公开状态页不能替代客户自己的监控、日志和合同核对。

OC 判断

SLA 不是稳定性的保险单，更像一张需要用户主动兑换、而且附带很多条件的优惠券。企业应把索赔证据收集做进事故响应流程，而不是等月底靠记忆补材料。

为什么重要

• 对开发者：事故复盘除了技术原因，还应保留地区、实例和精确时间线。
• 对企业：FinOps 可以把 SLA 额度申请变成固定流程，减少可追回成本的流失。
• 对用户：99.9% 并不意味着业务损失会得到赔偿，合同上限通常远低于真实损失。

参考来源

• SLA Credit Watch
• AWS Compute Service Level Agreement