チャットを止めて、スケジュールを始めてください。OpenClaw の HEARTBEAT.md と Cron チュートリアル

これは OpenClaw 執筆コンテストへの投稿です。最も個人的な AI セットアップは、同じ方法で廃れます。ツールを導入し、本当に使えそうな会話 3 回程度を行えば、存在を忘れるのです。タブが閉じます。アプリが埋もれます。「24/7 アシスタント」と呼んでいたのが、1 ヶ月に一度だけ、罪悪感を込めて訪れるチャットウィンドウへと変わります。解決策は単純です。自分の開始を待たず、AI にその役割を委ねてください。OpenClaw は、反応型チャットボットをあなたを促すものに変えるための 2 つの小さな基本機能、つまり cron job と HEARTBEAT.md を備えています。それぞれが単独で特別に光るものではありません。しかし、それらが組み合わさることは、思い出させなければならないアシスタントと、思い出させなくてもよいアシスタントの差です。この記事では、構成で 10 分以内に両者を解説します。openclaw onboard --install-daemon を実行し、ポート 18789 に動作する Gateway があることを前提とします。そうではありませんか、公式の「はじめまして」ガイドがその道筋を約 5 分で示します。2 つの形のプロアクティブさを見極める価値があります。なぜなら、それぞれが異なる方法で失敗するからです。Push はスケジュールされた出力です。午前 7 時の「あなたの日のためにこちらです」メッセージ。金曜日の 5 時の「実は、月曜日に約束したものを送ったでしょうか？」という促し。Push は、いつ送るべきかがはっきりしている時に素晴らしいものです。しかし、それは、送るべきかがはっきりしない時に絶望的です。何もなかった日曜日の要約は、すぐに雑音になります。そして、あなたは 1 ヶ月以内にチャンネルをミュートします。Pulse は、スケジュールされた出力がないスケジュールされた思考です。30 分ごとに、エージェントがルールブックを読み、現在の世の中の状態（あなたの最近のメッセージ、作業スペースのファイル、アクセス可能な任何东西）を鑑みて、あなたを中断すべきか判断します。多くの場合、それは中断しない判断を下します。しかし、その際にあなたは聞き入ります。なぜなら、それは価値があるからです。OpenClaw は、openclaw cron を介して push、HEARTBEAT.md を介して pulse を提供します。両方を使ってください。それらは異なる失敗モードをカバーします。openclaw cron はスケジュールタスクの基本機能です。ワンショットタイマー、固定間隔、時差を含んだ標準 Cron 式をサポートします。タスクは ~/.openclaw/cron/jobs.json に格納され、実行時ステートは隣接する jobs-state.json にあります。ここでは最も簡単な実用的なタスク — 午前 7 時に推しに Slack にプッシュされる日曜日の要約 — を示します: openclaw cron add \ --name "Morning brief" \ --cron "0 7 * * *" \ --tz "America/Los_Angeles" \ --session isolated \ --message "Summarize overnight updates." \ --announce \ --channel slack \ --to "channel:C1234567890" コピーペーストする前に理解すべきいくつかのフラグ: --session isolated は、実行のための新しいエージェントコンテキストを起動します。要約っぽい任何东西を使用するときにこれを有効にします。昨日の会話を今日の要約に流れ込ませたくないのです。--session main が代替方案です：タスクはあなたの進行中の会話の中で実行されます。これが真に連続性を必要とするもの（「私が月曜日に言及したものを解決したか確認する」）に保存してください。 --announce はタスクを発射してプッシュすることをします。これがない場合、出力はセッション履歴に書き込まれ、あなたは中断されません。たまにそれがあなたが望んだことですが、大抵はではありません。 --tz は渡航する場合に必須です。私はこれで苦しみました：私が PDT に設定したタスクが、私がニューヨークにいるとき 4 時に発火したのです。常に明示的に時差を設定してください。 管理は人体工学的です: openclaw cron list openclaw cron show openclaw cron runs --id --limit 50 openclaw cron remove runs サブコマンドが最も私が使用するのは、これが私が最も使用するのは、スケジュールされた要約が少し不自然と感じたときに、cron runs は N 回の実行と入出力を表示し、プロンプトが漂流しているか、モデルが漂流しているかを簡単に特定することを可能にします。 再試行が不可欠なレート制限のバグに追加するには、それを構成に追加してください: { cron: { enabled: true, store: "~/.openclaw/cron/jobs.json", maxConcurrentRuns: 1, retry: { maxAttempts: 3, backoffMs: [60000, 120000, 300000], retryOn: ["rate_limit", "overloaded", "network", "server_error"] } } } それは push です。10 行の CLI と、実際に予定通りに現れる AI があります。 ハートビートは、私がそれを使わないまで理解しなかった機能です

This is a submission for the OpenClaw Writing Challenge Most personal AI setups die the same way. You install the thing, have three genuinely useful conversations, and then forget it exists. The tab closes. The app gets buried. Your "24/7 assistant" becomes a chat window you visit once a week, guiltily, like a houseplant you forgot to water. The fix is simple: stop waiting for yourself to initiate. Let the AI initiate instead. OpenClaw ships with two small primitives that, combined, turn a reactive chatbot into something that nudges you. They are cron jobs and HEARTBEAT.md. Neither one is particularly glamorous on its own. Together they are the difference between an assistant you have to remember and one you can't. This post walks through both in under 10 minutes of config. I assume you've already run openclaw onboard --install-daemon and have a working Gateway on port 18789. If not, the official getting-started guide gets you there in about five minutes. There are two shapes of proactivity worth distinguishing, because they fail in different ways. Push is scheduled output. A 7:00 AM "here's your day" message. A Friday 5 PM "did you actually ship the thing you said you would on Monday?" nudge. Push is great when you know exactly what you want delivered and when. It is terrible when you don't — a daily summary of nothing becomes noise fast, and you'll mute the channel within a week. Pulse is scheduled reflection without scheduled output. Every 30 minutes, the agent reads a rubric, looks at the current state of the world (your recent messages, your workspace files, whatever it has access to), and decides whether to interrupt you. Most of the time it decides not to. When it does, you listen, because it earned it. OpenClaw gives you push via openclaw cron and pulse via HEARTBEAT.md. Use both. They cover different failure modes. openclaw cron is the scheduled-job primitive. It supports one-shot timers, fixed intervals, and standard cron expressions with timezone. Jobs are stored at ~/.openclaw/cron/jobs.json and runtime state lives next to it at jobs-state.json. Here's the simplest useful job — a daily 7 AM brief pushed to Slack: openclaw cron add \ --name "Morning brief" \ --cron "0 7 * * *" \ --tz "America/Los_Angeles" \ --session isolated \ --message "Summarize overnight updates." \ --announce \ --channel slack \ --to "channel:C1234567890" A few flags worth understanding before you copy-paste: --session isolated spins up a fresh agent context for the run. Use this for anything summarizing-ish. You do not want yesterday's conversation bleeding into today's brief — that's how you get an AI that rehashes last week's anxieties every morning. --session main is the alternative: the job runs inside your ongoing conversation. Save this for things that genuinely need continuity (e.g. "check whether we resolved the thing I mentioned on Tuesday"). --announce makes the job fire-and-push. Without it, the output goes to session history but doesn't interrupt you — occasionally what you want, mostly not. --tz is non-optional if you travel. I got burned on this: a job I set up in PDT started firing at 4 AM when I was in New York. Set the timezone explicitly, always. Management is ergonomic: openclaw cron list openclaw cron show openclaw cron runs --id --limit 50 openclaw cron remove The runs subcommand is the one I use most. When a scheduled brief starts feeling off, cron runs shows you the last N executions with inputs and outputs, which makes it easy to spot whether the prompt is drifting or the model is. If you want retries on the inevitable rate-limit blip, add them to config: { cron: { enabled: true, store: "~/.openclaw/cron/jobs.json", maxConcurrentRuns: 1, retry: { maxAttempts: 3, backoffMs: [60000, 120000, 300000], retryOn: ["rate_limit", "overloaded", "network", "server_error"] } } } That's push. Ten lines of CLI and you have an AI that actually shows up on schedule. The heartbeat is the feature I didn't understand until I used it for a week. By default, OpenClaw runs a heartbeat every 30 minutes. On each tick, the agent reads HEARTBEAT.md from your workspace and decides whether to interrupt you. If it decides no, it replies HEARTBEAT_OK and delivery is suppressed — you never see it. If it decides yes, you get a message. Crucially, the agent's judgment is constrained by whatever you write in that file. The file is the rubric. The default template is blunt: # Keep this file empty (or with only comments) to skip heartbeat API calls. # Add tasks below when you want the agent to check something periodically. Here's a version I've been running. It's not a prompt, it's a set of trip-wires: # Interrupt me only if one of these is true. Otherwise reply HEARTBEAT_OK. - It is a weekday between 9 AM and 5 PM local, AND my last activity signal is older than 90 minutes, AND I haven't marked a meeting or focus block for this window. Ask whether I got pulled off-track. - A cron job scheduled today has failed its last 2 runs. Tell me which one and stop there — don't propose fixes yet. - I mentioned a deadline in the last 48 hours that is now within 24 hours and I haven't acknowledged it. Surface it once. Don't re-surface. - Otherwise: HEARTBEAT_OK. Two things about this shape matter more than the specific rules. First, the default is silence. The last line — Otherwise: HEARTBEAT_OK — is what makes the whole thing tolerable. Without it you'll write rules that try to be quiet, but the model will find reasons to interrupt, because interruptions are more salient than their absence. Making silence the explicit default flips the prior. Second, every rule has a "don't re-surface" style clause. The failure mode of a pulse system isn't that it interrupts you once — it's that it interrupts you about the same thing twelve times. Build the escape hatch into the rubric itself. The agent won't do it for you. Tuning the interval lives in config: { agent: { heartbeat: { every: "30m" }, }, } Setting every: "0m" disables it entirely. I wouldn't go shorter than 15 minutes — the API costs add up, and more importantly the model starts pattern-matching on "it's been a while, I should say something" rather than on your actual rubric. Push and pulse cover opposite failure modes. Cron jobs are great at reliability ("the brief will be there at 7 AM, every day, forever") and bad at judgment ("is the brief worth sending today?"). Heartbeats are the reverse: the judgment is the whole point, but you can't rely on them for anything that must happen on a schedule. So the rule of thumb I've landed on: if the timing matters, make it a cron job. If the judgment matters, make it a heartbeat rule. A daily standup summary is a cron job. "Notice when I've been quiet too long" is a heartbeat rule. Trying to fit one into the other's role is where people get frustrated and conclude the AI isn't useful. Two honest gripes after a week of this setup. The heartbeat-vs-cron split is conceptually clean but operationally a little clumsy — they're configured in different places, surfaced in different CLI subcommands, and debugged differently. openclaw cron runs --id X gives you execution history for a job; there's no equivalent I've found for reviewing what the heartbeat decided on recent ticks. I'd pay real money for openclaw heartbeat runs --limit 50 showing me the last N decisions and the rubric excerpt each one cited. I'd also like the HEARTBEAT.md file to support per-channel overrides. Right now it's one rubric for the whole agent. A rule like "only interrupt me on Slack during work hours, Telegram otherwise" is the kind of thing every user eventually wants, and the current shape pushes that complexity into the rubric itself, where it doesn't belong. Neither of these is a blocker. Both would move the product from "useful with some thought" to "useful out of the box." If you try exactly one thing from this post, make it this: set a single cron job for tomorrow morning, and put HEARTBEAT_OK as the default in your heartbeat file. One push, one pulse, both with conservative defaults. Then resist the urge to add more for a week. Watch what the default-silent pulse flags. Watch what the 7 AM brief actually tells you. Add rules slowly, delete them faster. The mistake I made, and that I suspect most people make, is treating an AI assistant as a chat interface with extra features. It isn't. The chat interface is the demo. The scheduled behavior is the product.