UptimeRobot免费50个不够用UptimeKuma自建要一台VPSBetterStack免费只给10个三四十个站的批量监控选哪个不花冤枉钱：等发现挂了的时候蜘蛛已经爬了三天404恢复之后收录掉一截全白干了

手上有30个站的时候，最怕的不是排名掉、不是收录慢，而是站点挂了三天自己完全不知道。等发现的时候蜘蛛已经爬了三天404，恢复之后那批URL大概率被判成死链，收录掉一截，白干。

网站监控说起来简单——隔几秒去访问一下看有没有返回200。但真到批量监控三四十个站的时候，问题全冒出来了：免费工具限制数量，自建要加服务器成本，通知渠道能不能打通国内IM，误报多了会不会让自己神经衰弱。这篇把主流的几种方案拆开看，每个方案花多少钱、踩什么坑、适合什么规模的站点。

一、五款主流方案一张表看清楚

先列张表把几个方案的底牌摊开。每个方案的免费额度、监控频率、通知渠道、隐藏成本，一次性对比。

二、UptimeRobot免费版到底够不够用

先说最多人用的UptimeRobot。免费计划给50个监控项，5分钟检测一次，对大多数个人站长和中小站群来说是够的。

但有几个点需要注意。5分钟的检测间隔意味着一个站挂掉之后，最长可能要5分钟才收到通知。如果站点本身访问量不大，这5分钟不算什么。但如果你跑的是竞价落地页或者有时效性的活动页，5分钟的空白期可能就流失了不少转化。

通知渠道上，UptimeRobot免费版支持邮件、Slack、Telegram和Webhook。国内用户如果主力用微信，需要通过Webhook对接第三方服务（比如PushPlus、Server酱）把告警转到微信上。这个配置不算复杂，但多了一个中间环节就多了一个可能断掉的地方。

另一个容易被忽略的点是关键词验证。UptimeRobot支持检查返回页面中是否包含指定关键词——这个功能在免费版里是有的。比如你可以在监控规则里加一条"检查页面是否包含网站标题"，这样不仅能检测到HTTP 200，还能验证页面内容是否正常渲染，防止网站被挂马或者被篡改之后监控还显示"正常"的情况。批量监控时这个功能比单纯检测状态码有用得多。

三、Uptime Kuma自建到底要花多少钱

Uptime Kuma是开源项目，GitHub 50K+ star。它的核心卖点是"自建、无限监控、20秒检测间隔、90+通知渠道"。对有技术基础的站长来说，这是批量监控的最优解。

成本算一笔账。Uptime Kuma用Docker部署，内存占用大概150-200MB，一台最便宜的1核1G VPS就能跑——按年付大概$3-5/月，折合人民币20-35块一个月。如果监控量很大（几百个站点、检测间隔设到20秒），内存会涨到300-400MB，可能需要1核2G的配置，大概$6-8/月。

部署也不复杂。一台装了Docker的VPS，一行命令搞定：docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1。然后浏览器打开IP:3001，设置管理员账号，添加监控项，配置通知渠道，整个过程熟练的话十分钟以内。

但自建方案有个绕不开的问题：谁来监控监控者？如果你的Uptime Kuma服务器自己挂了，所有监控全部失效，你完全不会收到任何告警。解决方法是给这台监控服务器额外加一个外部监控——比如用UptimeRobot的免费额度单独监控Kuma服务器本身。这样一来就形成了"互相监控"的闭环。

四、BetterStack和其他SaaS方案值不值得看

BetterStack的界面和体验确实是所有SaaS监控里最好的，状态页做得尤其漂亮，还能记录每次故障的详细时间线和截图。但它免费版只给10个监控项，对于批量监控来说这个数量完全不够看。如果站点超过10个，要么付费（$24/月起），要么只能放弃。

Site24x7走的是企业级路线，功能最全——除了网站可用性监控，还覆盖服务器性能、数据库、网络设备、APM应用性能监控。但价格也最贵，基础版$9/月只给10个网站监控。对于纯做网站批量监控的场景来说，功能溢出太多，性价比不高。

国内也有一些监控平台比如阿里云云监控、腾讯云云拨测，优势是检测节点在国内，对国内服务器的监控准确度更高，通知也能直接走短信和电话。但免费额度普遍很少，批量监控基本上都要付费。如果站点全是国内服务器，且对告警响应速度要求极高（比如涉及交易），可以考虑这类方案。

五、通知渠道怎么配才不会漏掉告警

监控的最后一公里是通知。告警发出去了但你没看到，等于没有监控。通知渠道的选择和配置有几个原则。

第一原则：至少配两条不同渠道。一条即时通讯（微信/钉钉/飞书/Telegram），一条邮件。即时通讯负责第一时间触达，邮件负责留底归档。只配一条渠道的风险在于——万一那条渠道的服务也出问题了（比如Telegram宕机、企业微信Webhook失效），你就完全收不到告警了。

第二原则：国内用户优先走钉钉或飞书机器人。微信个人号没有官方Webhook接口，只能通过第三方服务（PushPlus、Server酱、WxPusher）中转。中转链路多一环就多一个故障点。钉钉和飞书的机器人Webhook是官方原生支持的，稳定性好很多，而且Uptime Kuma和UptimeRobot都原生支持这两个渠道的Webhook。

第三原则：设置告警静默期。凌晨三点到早上七点，非核心站点（比如内容站、博客）的告警可以静默。不然一条凌晨的误报告警就能毁掉一整晚的睡眠。Uptime Kuma支持按监控项设置通知时间窗口，UptimeRobot付费版也有类似功能。

六、误报比漏报更消磨人

这个问题很少人提，但实际运营中误报带来的困扰比漏报大得多。漏报只是你不知道站点挂了——但通常几分钟到几十分钟内你还是会发现的（用户反馈、自己访问、蜘蛛抓取异常）。误报不一样，一天十几条"网站已宕机→已恢复"的消息，三天之后你就会把通知关掉，然后真宕机的时候就再也收不到告警了。

误报的主要来源有三个：

网络抖动。监控节点到目标服务器之间的网络偶尔波动，超时几百毫秒，监控系统判定为宕机但实际网站正常。这种情况在国内服务器+海外监控节点的组合下尤其常见。解法是设置重试次数——不要一次超时就告警，连续两次或三次超时再触发通知。Uptime Kuma支持设置重试次数和重试间隔，建议设成重试2次、间隔10秒。

CDN或WAF拦截。监控请求触发了CDN的安全策略（比如Cloudflare的Bot Fight Mode），返回403或JS挑战页面。监控系统看到非200状态码就报故障，但实际上网站是好的，只是CDN把监控请求当成了攻击流量。解法是在CDN里把监控节点的IP加入白名单，或者把监控的User-Agent设成白名单。

SSL证书临近过期。监控系统在证书到期前30天开始报警，但你可能已经续期了只是还没部署。这种情况需要做SSL监控的告警阈值校准——把提前告警天数设短一些（比如7天），或者直接关掉SSL到期告警改用独立的证书监控工具。

七、不同站点规模怎么选

站群场景下还有一个额外需求：不仅要知道站点挂没挂，还要知道收录和排名有没有异常波动。纯粹的网站可用性监控只能告诉你站点能不能访问，但收录暴跌、关键词排名跳水这些问题是看不出来的。这部分需求就需要更上层的监控能力了。像UC建站系统内置的多站看板，就是把可用性监控和SEO数据监控（索引量变化、排名波动、流量异常）整合在一个面板里，可用性告警走即时通知，SEO异常走日报周报，两个维度互补。

八、监控搭好之后容易被忽略的三件事

监控这件事本质上是在"花最小的精力确保最大的确定性"。三四十个站同时在线的时候，你不可能一个个手动检查。但监控系统搭好之后，每天可能只需要花两分钟扫一眼面板，剩下的交给告警就行。这才是批量监控真正的价值——不是让你盯着屏幕看，而是让你不用盯着屏幕也能放心。