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.

The mental model: push vs. pulse

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.

Part 1: Push — a 7 AM morning brief with cron

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 <jobId>
openclaw cron runs --id <jobId> --limit 50
openclaw cron remove <jobId>

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.

Part 2: Pulse — proactive checks with HEARTBEAT.md

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.

Why this combination works

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.

What I'd change

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."

The actually-useful takeaway

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.