什么应该触发宕机告警
从访客会直接感受到的失败开始：首页没有响应、登录或结账路径返回错误、另一个系统依赖的 API endpoint 失败、DNS 不再解析，或 TLS 证书无效或接近过期到需要处理。
避免对每个单次失败请求都告警。来自一个探测节点的单次网络抖动可能只是噪音。对多数网站来说，更好的规则是在开启事故前要求连续两三次失败，最好还由不止一个探测节点确认。
谁应该先收到告警
第一条告警应发送给真正能开始修复的人：创始人、负责维护的自由职业者、代理商支持渠道，或值班工程师。共享收件箱或 Slack 频道可以，但前提是有人负责查看。
如果没有人拥有这个目的地，告警在实践中就不存在。网站仍然会先被客户发现；监控工具只是创建了一条没人看到的带时间戳记录。
实用的重试和升级时间线
对普通面向客户的网站，每 5 分钟检查，要求一个小的连续失败阈值，并在跨过阈值后立即告警。这样能在可预期窗口内发现真实停机，而不会因为每次瞬时网络失败就通知别人。
升级策略应匹配业务风险。宣传站可能先发邮件。结账流程、付费 API，或维护合同下的客户网站，应进入更快渠道，例如 Slack、Discord，或团队已经盯着的系统中的 webhook。
能加快响应的告警文案
有用的告警会说明什么失败、从哪里检查、什么时候开始，以及 monitor 原本期望看到什么。“首页连续两次检查返回 500”是可执行信息；“检测到网站问题”不是。
包含足够上下文，跳过第一轮猜测：URL、状态码、响应时间、TLS 或 DNS 失败，以及事故历史链接。故障期间，清晰比 clever wording 更重要。
如何减少误报
使用连续失败、探测节点和合理响应时间阈值。不要把响应时间告警设得太低，导致正常波动也变成事故。除非你能明确断言什么叫“健康”，否则不要监控预期会阻止机器人、要求会话，或因访客不同而大幅变化的页面。
复盘最初几次事故。如果每条告警都是噪音，就在人们学会静音频道前调整阈值。如果告警总是在客户投诉后才到，就缩短间隔或把告警路由到更醒目的地方。
Holter 如何处理宕机告警
Holter 从你的基础设施外部监控 URL、TLS、DNS、域名过期和 heartbeat check-in。你选择告警渠道和失败阈值，因此真实事故只会在 monitor 积累到足够值得关注的证据后打开。
Free 计划包含 5 个 monitor、5 分钟检查、无需信用卡，足够给真实网站设置可信宕机告警：首页、登录或 API、TLS、域名，以及一个给用户看不到的后台任务使用的 heartbeat。
Holter 为你监控这些风险：外部检测加 dead-man 心跳，覆盖静默失败。免费计划：5 个监控、5 分钟检测，无需信用卡。
免费创建可信宕机告警