OpenClaw 定时任务没通知，你应该这样做

很多人用 OpenClaw 做定时任务时，第一反应都是：任务明明跑了，为什么我收不到通知？

这个问题真正反直觉的地方在于：OpenClaw 不懂 OpenClaw，不知道如何正确设置定时任务。

所以你让它配置定时任务时，它未必知道当前该用 Heartbeat、OpenClaw Cron 还是 System Cron。最后就很容易出现一种情况：任务配上了，逻辑也跑了，但收不到通知。

1. 定时任务有 3 种方式，OpenClaw 要知道用哪种

OpenClaw 里常见的“定时任务”有三种：

• Heartbeat：主会话里的周期性巡检
• OpenClaw Cron：Gateway 内建的定时任务系统
• System Cron：Linux 自己的定时任务

它们都能定时做事，也都可以通知，但运行逻辑、使用场景、通知机制完全不一样。

2. Heartbeat 为什么常常“有检查、没通知”

Heartbeat 的本质不是准点发消息，而是：定期唤醒主会话，看看有没有值得处理的事。

它更像“巡检”，天然适合这种场景：

• 每 30 分钟看一次邮箱和日历，有重要信息再提醒
• 定期看看后台任务有没有跑完，有结果再顺手汇报

OpenClaw 文档里也写得很明确：Heartbeat 默认更像一种周期性巡检机制，而不是一个精确调度器。

如果你想让 Heartbeat 把结果发到外部 Channel，需要先在 ~/.openclaw/openclaw.json 里配置。比如：

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "every": "30m", // 每 30 分钟跑一次 Heartbeat
        "target": "last" // 如果有消息要发，就发到最近一次联系的目标
      }
    }
  }
}

注意 target 的默认值其实是 none。如果没有正确配置 target，或者任务最后只返回了 HEARTBEAT_OK，那结果就是：任务跑了，但你不会收到任何通知。

另外，虽然可以修改 Heartbeat 的 target 配置，让它具备发送通知的功能，但目前 OpenClaw GitHub 里有大量关于该功能无法使用的 issue。我亲测后也发现，设置 target=last 基本无效，通常还需要明确指定 channel 和 to，即便这样也依然不稳定。所以不推荐用 Heartbeat 跑定时任务。

3. OpenClaw Cron 能通知，但要分清 2 种模式

很多人以为 OpenClaw Cron 就是 System Cron 的壳，其实不是。

OpenClaw Cron 是 Gateway 内建调度器，支持 main session 和 isolated 两种执行模式。

3.1 main session

这种模式不是直接发消息，而是：

• Cron 先塞一个 system event
• 再唤醒 Heartbeat，或者等下一次 Heartbeat
• 最后由主会话回复，并路由到对应 Channel

换句话说，不是 Cron 自己直接通知你，而是 Cron 先去敲主会话的门，再由主会话决定怎么回复你。

一个场景示例是：

20 分钟后提醒我去开会

它的过程大概是：

• 你创建一个 one-shot Cron job
• 到时间后，Cron 往主会话里塞一条提醒事件
• 主会话被唤醒
• 主会话输出一条提醒消息
• 这条消息再被路由到你的 Telegram / Discord

最后的结果更像是：助手来提醒你一件事。

示例命令：

openclaw cron add \
  --name "Meeting reminder" \
  --at "20m" \
  --session main \
  --system-event "Reminder: meeting starts in 10 minutes." \
  --wake now \
  --delete-after-run

这里几个关键参数的意思是：

• --session main：这次任务跑在主会话里
• --system-event ...：往主会话塞一条事件，而不是直接生成独立任务
• --wake now：到点就立刻唤醒，不等下一次 Heartbeat

但要注意，main session 模式本身并没有独立的通知机制，最后还是依赖对话上下文或者 Heartbeat 这条链路把消息送出来，所以稳定性也不高。

3.2 isolated

这是很多人真正想要的模式。

isolated job 会启动一个独立的 cron:<jobId> 会话，不污染主会话历史。

一个场景示例是：

每小时检查一次 GitHub Issue，有新内容就直接通知我

它的过程大概是：

• Cron 到时间后单独启动一个独立任务
• 这个任务自己完成检查、筛选和整理
• 跑完后直接按配置把结果发出去
• 主会话不参与具体过程

最后的结果更像是：后台任务自己跑完，然后把结果直接推给你。

示例命令：

openclaw cron add \
  --name "Agents Radar" \
  --cron "0 * * * *" \
  --session isolated \
  --message "Check new GitHub issues and notify me if there is anything new." \
  --announce \
  --channel telegram \
  --to <chat_id>

这里几个关键参数的意思是：

• --session isolated：这次任务独立运行，不进入主会话
• --message ...：这次独立任务真正要执行的 Prompt
• --announce：跑完后直接把结果发出去
• --channel telegram：发到 Telegram
• --to <chat_id>：发给指定目标

在这种模式下，消息会由 OpenClaw 的 outbound channel adapters 直接发出去，不再绕主会话。

如果你的目标是定时跑一个 Agent 任务，并且稳定收到通知，那选它就对了。

4. System Cron 为什么也经常背锅

还有一类情况，是 OpenClaw 其实根本没用 OpenClaw Cron，而是用了 Linux 的 System Cron。

比如：

0 * * * * python3 monitor.py

这当然能定时执行，但它本身不认识 OpenClaw 的 Channel，也不认识 Session、Heartbeat、Delivery。

所以如果脚本里没有配置 Telegram API、Slack API 之类的通知逻辑，它就只是跑完了，不会凭空通知到你。

5. 定时任务类型如何选择

基于这个对比，我目前的结论是：只要你想跑定时任务且获得通知，就直接用 OpenClaw Cron 的 isolated 模式。

6. 最后

所以，很多“OpenClaw 定时任务收不到通知”的问题，根子在于：OpenClaw 并不懂如何选择并设置合适的定时任务类型，以及 OpenClaw 本身在通知功能上存在一些 Bug。

如果你也经常遇到这类问题，可以使用以下提示词，安装我已经封装好的 Skill：

安装 Skill：https://github.com/sonicrang/openclaw_skills/blob/main/openclaw-scheduler-guide/SKILL.md

它会判断用户意图。只要是涉及定时和通知任务，就会使用 OpenClaw Cron 的 isolated 模式，并且告诉 OpenClaw 该如何配置。