Heartbeat monitoring

Heartbeat monitoring checks that a job keeps running: the job sends a request to a unique URL each time it finishes, and an alert goes out when a request is late.

It turns ordinary monitoring around. Instead of the monitor calling your service, your cron job, backup script or queue worker calls the monitor. That catches failures that leave nothing to check from outside: a job that never started, crashed halfway or hangs.

Two settings define it: the period (how often the job runs) and the grace time (how late a ping may be before it counts as missed). Send the ping only after the work succeeded, so a job that runs but fails is caught too.

At a glance

0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://openuptime.app/api/heartbeat/<token>

In OpenUptime

In OpenUptime a heartbeat monitor goes down when no ping arrives within the period plus the grace time.

Read the cron job monitoring guide →

Questions

How long should the grace time be?

Longer than the job's normal variation in run time, so a slow night does not alert; short enough that a missed run is noticed before it matters. A few minutes for frequent jobs, up to an hour for daily ones.

What is the difference between a heartbeat and a health check?

A health check is a request the monitor sends to your service. A heartbeat is a request your job sends to the monitor. Use health checks for things that answer requests, heartbeats for things that run on their own.

Synthetic monitoringSynthetic monitoring checks a service by sending it requests on a schedule from outside, as a user would, rather than waiting for real traffic.False positive alertA false positive alert reports a failure that did not affect users, such as a single timed-out check caused by the network between the monitor and the server.DowntimeDowntime is the time during which a service is unavailable or does not work as expected.UptimeUptime is the share of a period during which a service worked as expected, usually given as a percentage such as 99.9%.

Monitor it with OpenUptime

Checks from one or several regions, alerts to the tools you use, and a status page for your customers. Free to start, open source under the MIT license.

Start monitoring See pricing

术语表

心跳监控（Heartbeat monitoring）

心跳监控用来确认任务一直在运行：任务每次完成时向一个专属 URL 发送请求，请求迟到时就发出告警。

它把普通监控的方向倒了过来。不是监控去请求你的服务，而是你的定时任务、备份脚本或队列消费者去请求监控。这样能发现那些从外部无从检查的故障：任务根本没启动、中途崩溃，或卡住不动。

它由两个设置决定：周期（任务多久运行一次）和宽限时间（请求最多可以迟到多久才算缺失）。只在任务成功完成后才发送请求，这样运行了但失败的任务也能被发现。

速览

0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://openuptime.app/api/heartbeat/<token>

在 OpenUptime 中

在 OpenUptime 中，如果在周期加宽限时间内没有收到请求，心跳监控就会判定为宕机。

阅读定时任务监控指南 →

常见问题

宽限时间设多长合适？

要比任务运行时长的正常波动更长，这样某天跑得慢也不会误报；又要足够短，在漏跑造成影响之前就能发现。频繁运行的任务设几分钟，每天一次的任务最多一小时左右。

心跳和健康检查有什么区别？

健康检查是监控发给你服务的请求。心跳是你的任务发给监控的请求。能响应请求的服务用健康检查，自己按计划运行的任务用心跳。

主动监控（Synthetic monitoring）主动监控（synthetic monitoring）是按计划从外部向服务发送请求来检查它，就像用户在访问一样，而不是等真实流量来发现问题。误报（False positive alert）误报是指告警报告了一个并未影响用户的故障，例如监控与服务器之间的网络问题导致某一次检查超时。停机时间（Downtime）停机时间是指服务不可用、或无法按预期工作的那段时间。可用时间（Uptime）Uptime 指在一段时间内，服务按预期正常工作的时间所占的比例，通常用百分比表示，例如 99.9%。

用 OpenUptime 监控

从一个或多个区域检查，告警发到你常用的工具，还有面向客户的状态页。免费开始使用，以 MIT 许可证开源。

开始监控查看价格