Push监控会主动执行我的cron任务吗？

不会。cron负责启动任务，脚本负责请求Push URL，Uptime Kuma只接收状态并检查心跳是否超时。

每十五分钟运行一次，心跳能直接填900秒吗？

不宜卡住边界。相邻两次完成的间隔会受耗时变化影响；示例预留三分钟耗时和一分钟抖动，填1140秒。

只发成功心跳，不发down可以吗？

可以，失败和漏跑都会因后续没有成功心跳而超时，但主动上报down能保留脚本退出码，通常也更早暴露失败。

为什么curl成功退出，任务却没有完成？

curl只说明上报请求完成。应先检查业务脚本退出码和产物，再决定发up还是down；不要无条件在最后发up。

Push URL可以放进公开仓库吗？

不可以。URL中的Token可用于提交该监控状态。泄漏后在监控编辑页重置Token、保存，并更新任务配置。

同一个Push URL能监控三台机器吗？

不适合判断各机器是否漏跑。一台持续上报就可能掩盖其他机器停止，应该为每个需要独立告警的任务实例创建监控。

Uptime Kuma监控定时任务 | Push心跳接入cron

每十五分钟导出一次订单数据，值得监控的是“这次导出完成了没有”。让脚本完成后向Uptime Kuma发送Push心跳，才能把监控状态与结果连起来。另设一个每分钟报成功的定时器，只能证明那个定时器还在运行。

下面以Linux上的固定周期导出为例。假设你已有可访问的Kuma实例、通知渠道，以及能用退出码表达成功失败的脚本；不涉及安装服务或恢复备份。核验基线是官方2.5.4版本，示例未在真实业务环境运行。

Push究竟在等什么？

Push由任务机器向Kuma发请求，任务机器不需要为此开放一个被探测的端口。上报位置决定了绿色状态的含义：放在脚本开头，表示启动过；放在导出和校验完成之后，才表示这轮工作通过了你的检查。

把需要发现的情况分开，才能选对触发方式。

任务情况	包装脚本动作	希望看到的信号
导出并校验成功	发送up	新的成功心跳
命令返回非零退出码	发送down及退出码	失败状态与简短消息
cron未启动或进程卡住	没有完成上报	心跳窗口超时
导出成功但上报网络失败	本地记录上报错误	本地日志与Kuma超时结合判断

如果导出脚本会吞掉错误、无论结果都返回零，先修正它。数据库备份还要分清产物范围，可对照Supabase数据库与Storage备份；心跳不会替你检查备份能否恢复。

十五分钟任务，心跳间隔填多少？

示例周期是900秒，预计最长执行180秒，再留60秒调度与网络余量，心跳间隔设为1140秒。这是按本例条件选的值，不是Kuma默认值。它覆盖上轮很快完成、下一轮跑满三分钟时的完成时间差。

心跳检查逻辑依据距上次心跳的时间判断窗口，不会读取你的crontab。填900秒可能把正常的耗时波动当成漏跑；填两小时又会推迟发现异常。若最近一次成功在10:01，示例窗口大约到10:20，并非固定在10:19检查所有任务。

第一步：新增一个专用Push监控

在新增监控中选择Push，名称写成“订单导出·每15分钟”。心跳间隔填1140秒，重试次数先设0，选择已配置的通知渠道，保存后复制Push URL。不要开启反向状态，也不要把测试监控放进维护时段。

官方编辑表单会提供Push URL和重置Token按钮。Token不要提交公开仓库，也不要贴进截图。泄漏后用重置按钮生成新值并保存，再更新脚本中的地址；旧配置会停止上报，所以更新时要一并检查下一次执行。一个独立告警对象用一个Token；多个任务共用地址，会让正常任务持续报到，掩盖另一个任务漏跑。

第二步：把上报放在任务退出之后

下面是自行组织的包装脚本示例。保存为/opt/jobs/export-with-heartbeat.sh，将域名与Token替换成自己的地址，去掉复制URL中问号及其后参数。实际任务/opt/jobs/export.sh必须已经存在、有执行权限，并完成导出及必要校验。先确认/usr/bin/curl可用；若curl安装在其他位置，修改脚本中的绝对路径。

#!/bin/bash
PUSH_URL='https://kuma.example.com/api/push/REPLACE_TOKEN'

/opt/jobs/export.sh
job_rc=$?
status=down
[ "$job_rc" -eq 0 ] && status=up

if ! /usr/bin/curl --fail --silent --show-error \
  --connect-timeout 5 --max-time 15 --get \
  --data-urlencode "status=$status" \
  --data-urlencode "msg=export_exit_$job_rc" \
  "$PUSH_URL"; then
  echo "heartbeat_delivery_failed job_exit=$job_rc" >&2
  [ "$job_rc" -eq 0 ] && exit 75
fi
exit "$job_rc"

Push接口实现接收状态与消息参数，正常响应包含ok: true。消息只发退出码，详细订单内容留在任务日志中。这里保留原任务失败码；任务成功但请求失败时，包装器用75表达“上报未完成”，这是本例约定。

curl手册中的超时选项限制上报等待，URL编码选项处理参数。这个简版只检查curl退出码，不自动校验响应JSON。首次验证要在日志里确认{"ok":true}，并核对Kuma记录；反向代理的跳转或登录HTML可能使curl成功退出，却没有写入心跳。不要为了重发心跳自动重跑导出，以免重复写入数据。

第三步：接入cron并保留执行日志

由运行任务的账号保存脚本，确认它能读取配置、写入导出目录。为包装脚本收紧权限，再编辑同一账号的crontab：

chmod 700 /opt/jobs/export-with-heartbeat.sh
crontab -e

加入以下示例计划，日志目录须事先创建且可写：

*/15 * * * * /bin/bash /opt/jobs/export-with-heartbeat.sh >> /opt/jobs/export-heartbeat.log 2>&1

不要依赖交互终端加载的环境变量。实际导出脚本中也使用确定的路径，并安排日志轮转。若任务可能超过十五分钟，要先处理并发执行；Push不会阻止上一轮和下一轮互相覆盖。文件搬运脚本可继续看rclone的copy与sync选择。

怎样证明失败和漏跑都能通知？

第四步，复制一份包装器并改用专用测试监控的URL，把导出命令临时换成/bin/true，手动运行后应看到export_exit_0。再换成/bin/false运行，应出现down和export_exit_1，并收到失败通知。不要修改生产导出来制造失败。

第五步，把测试副本改回/bin/true，重新发一次成功心跳，再停用调用该副本的测试cron计划。超过1140秒窗口后，应出现无心跳的失败记录和通知；随后恢复计划，观察下一次成功上报。仅点击通知渠道的测试按钮，并没有验证这条漏跑链路。

本例重试为0，是为了避免验收时混入Pending等待。以后增加重试，会改变失败确认节奏；每日单次任务尤其不宜直接照搬网站探测的重试设置。每周一、周五这类不等间隔计划，也不能用一个固定秒数准确表达截止时间。这里覆盖固定周期任务，更多部署工具可从工具栈目录继续查找。

Uptime Kuma监控定时任务