替代简报

定时监控

AI 能替代 Cronitor？

编辑结论可替代提示词已精选

就是一个心跳接口加上超时告警，一百来行代码套了个 SaaS 外壳，自己做完全没问题。

最近复核 2026-10-04 · DeepFeather 编辑部

已知限制公开状态页与团队功能；短信、PagerDuty 等告警路由

做一个心跳监控服务：接收定时任务发来的 HTTP ping，按宽限时间判断是否漏跑，漏跑就发告警。

构建个人替代版 →

快速判断

价格: 每月 10 美元
年标价: 每年 120 美元
可替代范围: 做一个心跳监控服务：接收定时任务发来的 HTTP ping，按宽限时间判断是否漏跑，漏跑就发告警。
构建时间: 2–4 小时

构建提示词已审阅提示词 · 尚未运行

提示词

提示词已精选

帮我做一个类似 Cronitor / Healthchecks 的定时任务监控。要求：

- 每个任务有唯一的 ping 地址（/ping/:uuid），crontab 里只需追加 `&& curl -fsS <url>`，并写进文档。
- 通过带 Basic Auth 的 /admin 页面在 SQLite 中定义任务：名称、预期周期（例如每 60 分钟）和宽限时间；记录每次 ping 的时间。
- 调度循环检查每个任务：当前时间超过“上次 ping + 周期 + 宽限”就告警，写明任务名和延迟多久；恢复时再发一次。每次状态变化只告警一次。
- /admin 看板每个任务一行，用绿、黄、红圆点显示状态，并显示上次 ping 时间。
- 告警先支持邮件和一个 Webhook。

复制或在代理中打开

先阅读提示词；准备开工时再选择启动方式。

$ 在代理中打开（已预填提示词）或直接复制

Build Pack

自建 Cronitor 替代品：执行方案

自己做之前先看清：要做什么、不做什么、怎么算做成。用什么工具和提示词都可以，按验收测试判断结果。

预计耗时: 2–4 小时
预计月成本: $0–6/月
订阅价（对照）: $10/月 · Standard

要做的

为每个定时任务生成专属心跳地址（/ping/:uuid），在 crontab 命令成功执行后通过 curl 调用
支持显式失败上报端点（/ping/:uuid/fail），请求正文会直接附带在告警消息中
在 SQLite 中定义任务的名称、预期运行周期与宽限时间，并记录每次心跳的时间戳
后台调度循环定期扫描，一旦当前时间超过「上次心跳 + 周期 + 宽限时间」即标记为延迟
仅在状态发生切换（延迟、失败、恢复正常）时向 Discord、Slack 或 Telegram 发送一次 Webhook 告警
带 Basic Auth 保护的 /admin 看板：展示状态指示灯、距离上次心跳的相对时间与 24 小时内联 SVG 直方图

明确不做

解析复杂的 Cron 表达式——任务完全按固定预期周期加宽限时间判断
短信、电话语音呼入或 PagerDuty 值班轮转升级策略
公开状态页、多团队权限或多用户协作体系
对监控器自身的交叉监控：如果部署监控服务的机器宕机，不会发出告警

数据模型

jobsid (uuid)nameperiod_secondsgrace_secondsstatelast_ping_atstate 取值为 up、late 或 failed；仅在状态变化时触发告警
pingsidjob_idtskind (ok/fail)body在 (job_id, ts) 上建索引以快速渲染 24 小时心跳直方图

实施步骤

服务骨架与建表启动单进程 Web 服务并初始化 jobs 与 pings 表，在 (job_id, ts) 上建立索引。
心跳接收端点/ping/:uuid 记录正常心跳；/ping/:uuid/fail 记录失败状态与请求正文；未知 uuid 返回 404。
超时巡检循环每 30 至 60 秒扫描一次，当 now > last_ping + period + grace 时将任务标记为 late，收到新心跳后恢复为 up。
状态切换告警仅在状态跃迁（up → late、任意状态 → failed、late/failed → up）时调用 Webhook，写明任务名与延迟时长。
管理后台页面用 Basic Auth 保护 /admin 页面，支持增删改任务，展示红绿状态灯、上次心跳时间与 24 小时 SVG 直方图。
守护配置与文档提供 systemd 单元文件、.env.example 与说明 `&& curl -fsS <url>` 用法的 README。

验收测试

在每分钟运行的 crontab 命令末尾追加 `&& curl -fsS <ping url>`心跳记录正常入库，后台看板状态灯显示绿色
暂停该定时任务并等待超过「周期 + 宽限时间」准确收到一条延迟告警，且后续不会重复刷屏
重新恢复运行该定时任务收到一条恢复正常告警，此后保持静默
带请求正文调用 curl /ping/:uuid/fail收到的失败告警中包含传入的错误正文
强制杀掉监控进程systemd 自动重启进程，已有任务与心跳历史完好无损

只能由你完成

将监控服务部署在与被监控任务不同的独立机器上
在 Discord、Slack 或 Telegram 中创建机器人 Webhook 并将地址填入 .env
在每条需要监控的真实 crontab 任务末尾加上 curl 心跳调用
根据每个任务的实际执行耗时设定合理的周期与宽限秒数

成本说明

如果部署在你已有的闲置服务器上成本为 $0；若单独租用一台入门级轻量 VPS，每月通常在几美元以内，具体取决于云厂商定价。

成本来源: cronitor.io (核对 2026-10-04) · hetzner.com (核对 2026-10-04)

AI 能做出什么

做一个心跳监控服务：接收定时任务发来的 HTTP ping，按宽限时间判断是否漏跑，漏跑就发告警。

提示词经过编辑审阅；尚无已完成构建记录。

真实取舍

为什么还有人付费

付钱的人买的是状态页、团队功能和多渠道告警路由（短信、PagerDuty），以及监控服务本身不会和被监控的机器一起宕掉。

你会失去什么

公开状态页与团队功能

短信、PagerDuty 等告警路由

Cron 表达式分析

独立于你自己服务器的可用性

先用现成软件

现成方案 · 不想自建就用这些

Healthchecks成熟的开源定时任务心跳监控服务↗

证据台账

这页究竟能证明什么

判断回答“能否替代”，证据等级记录 DeepFeather 真正核对过什么。

阅读方法论 →

证据等级

提示词已精选

提示词经过编辑审阅；尚无已完成构建记录。

价格参考每月 10 美元

Standard

查看价格来源 ↗价格核对 2026-10-04

替代边界做一个心跳监控服务：接收定时任务发来的 HTTP ping，按宽限时间判断是否漏跑，漏跑就发告警。

已知限制 · 公开状态页与团队功能；短信、PagerDuty 等告警路由

构建反馈

你实际尝试了吗？

提交结果后会进入人工证据队列，不会自动改变编辑结论。

← 回到执行方案范围