设置可用性监控

三种类型，至少选一种

您可以直接监控首页 URL——对于静态网站来说这没问题。但对于有数据库和依赖服务的应用，首页即使在数据库不可达时也可能返回 200（缓存的 HTML、静态降级页、通用错误页）。专门构建的 /health 端点能区分三个层级：

• 存活检查（Liveness）——"进程正在运行并响应请求。"一行代码即可实现：app.get('/health', (req, res) => res.send('ok'))。适合检测进程崩溃，但无法检测依赖故障。
• 就绪检查（Readiness）——"进程正在运行，并且能与其依赖通信。"检查 Postgres 是否响应；检查 Redis 是否响应；检查所有必要的外部服务是否可达。全部通过则返回 200，否则返回 503 并附带详细信息。
• 深度检查（Deep health）——与就绪检查相同，但检查项更多（队列长度、近期错误率等）。适用于状态页面和监控面板；通常响应太慢，不适合每分钟的可用性探测。

对于可用性监控，就绪检查是最合适的形式：

app.get('/health', async (req, res) => {
  try {
    await db.query('SELECT 1');
    await redis.ping();
    res.json({ status: 'ok', db: 'ok', redis: 'ok' });
  } catch (err) {
    res.status(503).json({ status: 'degraded', error: err.message });
  }
});

这样，/health 返回 200 就意味着"进程存活，且依赖可达"——比监控首页提供了更有力的信号。

免费套餐满足大多数个人需求

前往 uptimerobot.com 注册。免费套餐包含 50 个监控器，5 分钟间隔。（付费 Solo 套餐每月 $7，支持 1 分钟间隔和短信通知。）

进入控制台 → + New Monitor：

• Monitor Type（监控类型）：HTTP(s)。
• Friendly Name（友好名称）："Mybrand API" 或类似名称——会显示在告警中。
• URL：https://mybrand.com/health。
• Monitoring Interval（监控间隔）：5 分钟（免费）或 1 分钟（付费）。
• Monitor Timeout（超时时间）：30 秒。响应超时的请求计为宕机。
• Advanced → Keyword Monitoring（关键词监控）：可选但实用。将关键词设为 "ok"，类型选"Yes — alert when keyword does not exist"。这样监控器不仅检查 HTTP 状态码，还会核实响应体中是否包含该字符串。那些返回 200 但附带错误信息的页面再也骗不过它了。

保存后，监控器会在一分钟内开始探测，响应时间图表随即开始填充数据。

邮件是默认选项；Slack / Discord 能精准唤醒责任人

UptimeRobot 控制台 → My Settings → Alert Contacts → Add Alert Contact。每个"联系人"对应一个告警目标：

• 邮件——默认使用注册邮箱。免费。
• Slack——类型选 Slack，粘贴 Incoming Webhook URL。在 Slack 中：管理员在 <workspace>.slack.com/apps 搜索"Incoming Webhooks"→ 选择频道 → 复制 URL。告警会以监控器名称和宕机时长的形式发送到该频道。
• Discord——同理。Discord Webhook URL 来自频道的集成设置。
• 短信——仅限付费套餐。适合"凌晨 3 点生产环境宕机时叫醒我"的场景。
• Webhook——用于接入自有系统（PagerDuty、Opsgenie、自定义系统）。状态变更时，UptimeRobot 会 POST 一个 JSON 数据包。

添加联系人后，编辑监控器并勾选哪些联系人应接收其告警。生产监控器通常同时启用邮件、Slack 和短信；测试环境监控器仅启用邮件。

让告警真正有意义的关键设置

对每次抖动都发出告警的监控器，最终会沦为背景噪音。三个设置可以改善这一问题：

• 宽限期（连续失败次数）：仅在 URL 连续失败 N 次后才发出告警。默认值 1 过于激进——建议设为 2 或 3。单次瞬间抖动不再打扰您，真正的故障仍会在 10–15 分钟内触发告警。
• 多区域确认：在 UptimeRobot Pro 及竞品中，仅当多个监控区域均认定网站宕机时才发出告警。有效减少单区域网络问题导致的误报。
• 维护窗口：将计划内的停机时间（发布窗口、计划维护）设为维护期，避免监控器在此期间发出告警。UptimeRobot：监控器 → Maintenance Window → 循环或一次性。

目标是"每条告警都是真实的，每次真实故障都有告警"。朝任何一个方向偏移都会削弱监控的价值。

向用户公开服务可用性

状态页面（status.mybrand.com）向用户展示您的服务各部分是否正常运行。出现问题时，用户查看状态页面而不是发邮件给客服。一切正常时，状态页面也是一种信任背书。

• UptimeRobot 内置公开状态页面——免费，与您的监控器绑定。控制台 → Status Pages → Create。默认使用 UptimeRobot 子域名；付费套餐支持自定义域名。三分钟即可配置完成。
• Better Stack / Better Uptime——竞品服务，提供更丰富的状态页面（故障历史、计划维护公告、订阅通知）。仅限付费但价格合理；如果您有付费用户，值得考虑。
• Atlassian Statuspage——企业标准方案。价格昂贵（$29+/月），对小项目而言过于复杂。
• Cachet 或 Upptime 自托管——开源状态页面。免费但有运维成本。

对于大多数用户量低于 1 万的项目，UptimeRobot 免费状态页面已经足够。只有当用户开始要求查看故障历史时，再考虑升级。

悄悄停止运行的 cron 任务

HTTP 可用性监控只能捕获 HTTP 层面的故障。另一种常见的无声故障是：一个 cron 任务（夜间备份、每周摘要邮件、每小时清理）已经中断两周，却无人知晓。

解决方案：使用 Healthchecks.io（最多 20 个检查项免费）等服务，为每个 cron 任务生成一个唯一 URL。任务每次成功执行后向该 URL 发送探针。如果探针在预期时间内停止到达，Healthchecks 就会发出告警。

# In your cron job script, last line:
curl -fsS --retry 3 https://hc-ping.com/<your-unique-uuid> > /dev/null

# In crontab:
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://hc-ping.com/<uuid>

Healthchecks 知晓预期的执行计划（您自行配置），并在探针超期时通知您。这对备份任务尤为有用——"备份是否执行"这个问题，往往只有在需要还原数据的那一天才会被追问。