可用性监控，已包含在 Core Web Vitals 中

网站看着一切正常，订单却已经停了

服务器停止响应，CDN 却还在返回缓存的首页。或者一次发布搞坏了结账页，其他页面却全都没事。直到客户发邮件询问为什么无法支付，才有人发觉。

CoreDash 会同时监控这两种情况，而且与 Core Web Vitals 放在同一个项目里。

网站宕机时，收到邮件和 Slack 消息

当网站宕机或页面返回错误状态时，你会收到一封邮件和一条 Slack 消息；恢复正常时，还会再收到一条。把关键页面添加进来——先从首页和结账页开始，CoreDash 每 30 分钟就会对每个页面检查一次。

监控项只有在来自两台不同服务器的检查连续失败两次后，状态才会变为 Down，因此偶发的网络抖动不会把你吵醒。

所有监控的站点与页面集中在一个列表中，展示过去 7 天的可用率，并标出两周内即将到期的所有证书。

看清 CDN 掩盖的宕机

服务器宕机时，CDN 依然可以继续返回缓存页面。首页照常能打开，但已登录用户、购物车以及所有未缓存的页面都会报错。CoreDash 依然能将站点标记为 Down：添加或编辑监控项时，在 Advanced 下输入服务器的 IP 地址，每次检查就会绕过 CDN，直接向服务器本身发起请求。

访客的等待时间，有多少耗在服务器上

在这个例子中，访客的等待时间约有一半耗在服务器上。CoreDash 会把每次检查的响应时间与真实访客在 p75 下的 TTFB 并列展示：探测端测得约 950 ms，每天傍晚出现峰值，而访客端则是 1.92 秒。

在服务器响应之前，最大的图片或标题根本无法呈现，因此要让这里的 LCP 变快，得先从服务器入手。

及时发现上次发布搞坏的结账页

发布之后，首页可能依然正常响应，结账页却显示“页面未找到”，而只挂在首页的监控根本看不出任何异常。

这里结账页配有专门的监控项。它正常运行了五天，但自两天前发布后便开始返回 404，CoreDash 将其标记为 Unexpected status。这同样会向你发送邮件和 Slack 消息，等到结账页恢复正常后还会再发送一条。

防火墙不误报，提前两周发现即将到期的证书

防火墙拦截探测请求时，绝不会触发宕机告警。监控状态会显示为 Blocked，并附带指向解决方法的链接，且不会将其计入宕机时间。

监控列表还会统计 14 天内即将到期的所有证书。就算忘记续签，在浏览器开始警告访客的两周前，这里就会提前提示。

19:50 宕机之后会发生什么

服务器在 19:50 停止响应。20:00 时第一台服务器未收到响应，监控状态变为 Failing；此时尚未发送任何通知。半小时后，第二台服务器同样未收到响应。监控状态转为 Down，邮件和 Slack 消息随即发出。

重新收到响应的第一次检查时，监控状态立即变为 Up，并以同样的方式发出警报解除通知。取决于服务器停机的具体时间点，你会在 30 到 60 分钟后收到通知。

就在团队日常打开的项目里

每个监控项都归属于一个 CoreDash 项目，项目成员都能在同一个站点的 LCP、INP 和 CLS 旁直接看到它。你现有的订阅以及免费试用均已包含该功能。在询问移动端 LCP 为何上升的同一个对话中，你也可以直接问 Claude “这周我的网站宕机了吗？”。将 Claude 接入 CoreDash。

何时需要专用的可用性监控工具

CoreDash 从单一大区的两台服务器每 30 分钟检查一次，并通过邮件和 Slack 发送告警。两次检查之间的短暂宕机可能会漏掉，而且它不提供公开状态页，也不支持短信。如果需要从多个国家每分钟检查一次，专用的可用性监控工具确实值得付费。

但若只是想确认网站和结账页是否正常工作，以及服务器响应有多快，你完全不需要额外工具。它已经内置在你的 CoreDash 项目中，无需额外费用。