What “active tasks” in HEARTBEAT.md actually means
If you use WordPress, marketing tools, or any AI agent that needs to check things on a schedule, the mistake is usually the same: people write vague reminders instead of task instructions. A heartbeat file is not a note to yourself. It is a control panel for what the agent should inspect, what counts as done, and what gets written back after the run.
In practice, active tasks are the checks that cause action. They review memory, scan for changes, make a decision, and update state. Passive checks only observe. They read files, glance at timestamps, or confirm that nothing changed. Passive checks are useful, but they do not move the system forward unless an active task follows them.
That distinction matters because most missed heartbeats are not scheduling failures. They are instruction failures. The agent ran, but the task definition was too fuzzy to trigger any meaningful work.
What counts as an active task vs a passive check
A good active task has four parts:
- Trigger — when the check should happen.
- Action — what the agent should do.
- Decision — what qualifies as important enough to keep.
- Writeback — what gets updated so the next run knows what happened.
A passive check usually stops at observation. For example, “read the latest memory log” is passive. “Read the latest memory log, extract any durable decision, append it to MEMORY.md, and record the run in heartbeat-state.json” is active.
For content and marketing workflows, active tasks are the ones that keep the machine honest:
- Pulling fresh campaign notes into long-term memory
- Checking whether draft ideas are still relevant
- Detecting broken links or stale offers
- Flagging pages that should be refreshed
- Recording that a check actually happened
How HEARTBEAT.md active tasks actually work
Think of HEARTBEAT.md as the rulebook and heartbeat-state.json as the receipt. The markdown file tells the agent what to do. The JSON file proves it ran.
Below is a full copy-paste example you can adapt. It is written for a content or marketing workflow, but the structure works for almost any agent that needs scheduled checks.
# HEARTBEAT.md — Scheduled Active Tasks for an AI Agent
## Purpose
Keep the agent doing useful periodic work instead of just sitting idle.
## Rules
- Run during normal hours only, unless a task is marked urgent.
- Update long-term memory only when a decision, lesson, or durable fact is found.
- Write task status to memory/heartbeat-state.json after every run.
- If a task has nothing meaningful to do, record that it ran and skipped for a real reason.
- Do not invent work. If a source is unavailable, mark the task as deferred.
## Active Tasks
### 1) Memory maintenance
Cadence: every 30 minutes during active sessions
Goal: capture durable decisions and prune stale notes
Steps:
1. Read the latest daily memory notes.
2. Extract decisions, open loops, and recurring patterns.
3. Append only durable items to MEMORY.md.
4. Record the run timestamp in heartbeat-state.json.
### 2) Content pipeline review
Cadence: weekdays at 09:00 and 15:00
Goal: keep drafts and ideas moving
Steps:
1. Check the draft queue for stalled posts.
2. Identify anything blocked by missing research, images, or approvals.
3. Move one item forward or record why it cannot move.
4. Save the status update in heartbeat-state.json.
### 3) SEO decay scan
Cadence: daily
Goal: detect pages or topics that need a refresh
Steps:
1. Review posts that target keywords with declining traction.
2. Flag pages with outdated examples, broken claims, or thin intros.
3. Suggest refresh candidates in a short note.
4. Mark the scan complete in heartbeat-state.json.
### 4) Link health check
Cadence: daily
Goal: catch broken or redirected links before they pile up
Steps:
1. Check recently edited posts for external links.
2. Confirm the link still resolves and still matches the intended source.
3. List any failures clearly.
4. Record the check outcome in heartbeat-state.json.
### 5) Weekly summary
Cadence: Friday at 16:30
Goal: produce a short operational summary
Steps:
1. Review the week’s completed checks.
2. Note patterns, blockers, and repeat failures.
3. Write a short summary for the owner.
4. Update heartbeat-state.json with the weekly checkpoint.
Notice what this does well. It names the task, sets cadence, defines the output, and makes the writeback part of the job. That is the difference between a reminder and a system.
If you want the task to feel real to the agent, make the steps concrete. Use verbs like read, compare, flag, append, and record. Avoid vague phrasing like “keep an eye on things” or “check if needed.” Those do not tell the model when to act.
5 active task patterns worth setting up
These are the five patterns I would set up first if I were running an agent for content, marketing, or operations.
1) Memory maintenance
This is the backbone. The agent reads recent notes and extracts only what should survive beyond today.
### Memory maintenance
Cadence: every 30 minutes
Steps:
1. Read today's notes.
2. Extract decisions, commitments, and repeated blockers.
3. Append durable items to MEMORY.md.
4. Record the run time in heartbeat-state.json.2) Draft queue triage
Useful when your content calendar gets messy. The agent looks for posts that are stuck and moves the most important one forward.
### Draft queue triage
Cadence: weekdays at 09:00
Steps:
1. Scan drafts for missing research, titles, or images.
2. Pick the highest-value stalled draft.
3. Resolve one blocker or write the blocker down.
4. Update heartbeat-state.json with the result.3) SEO opportunity scan
This catches topics worth revisiting before they decay. It works especially well if you publish regularly and want compounding traffic.
### SEO opportunity scan
Cadence: daily
Steps:
1. Review keywords with recent movement.
2. Flag posts that need a better intro, fresher examples, or stronger internal links.
3. Save the best refresh candidate.
4. Write the scan result to heartbeat-state.json.4) Link and asset check
Great for reducing silent damage. Broken links, expired embeds, and missing media usually go unnoticed until a human spots them late.
### Link and asset check
Cadence: daily
Steps:
1. Check external links in recently edited posts.
2. Verify image URLs or embeds still load.
3. List any failures by post title.
4. Mark the check complete in heartbeat-state.json.5) Weekly performance recap
This is the sanity check. It turns scattered activity into a short summary the owner can actually use.
### Weekly performance recap
Cadence: Friday afternoon
Steps:
1. Review completed active tasks from the week.
2. Summarize wins, blockers, and repeated skips.
3. Highlight one change for next week.
4. Record the recap timestamp in heartbeat-state.json.Common mistakes that cause tasks to silently skip
- Writing passive instructions only — If the file says “review” but never says what to do with the review, nothing useful happens.
- Hiding the cadence — If the check time is unclear, the agent may treat it like background reading instead of a real task.
- Skipping writeback — Without state updates, you cannot tell whether the run happened or was skipped.
- Making the task too broad — “Improve the site” is not a heartbeat task. “Flag three stale pages” is.
- Forgetting quiet hours — If the system is meant to stay calm overnight, encode that rule directly.
- Mixing too many goals in one task — One task, one outcome. Otherwise the agent does nothing because it cannot rank the work.
The easiest fix is to make every task fail loudly in the instructions. That means giving it a fallback action like “record skipped: source unavailable” or “record skipped: no durable change found.” Silence is the enemy.
How to track whether your tasks ran
That is where memory/heartbeat-state.json comes in. It should be simple, readable, and easy to update on every run. The point is not sophistication. The point is proof.
{
"lastChecks": {
"memory_maintenance": 1778195580,
"content_pipeline_review": 1778199180,
"seo_opportunity_scan": 1778202780,
"link_health_check": 1778206380,
"weekly_summary": 1778210000
},
"lastResults": {
"memory_maintenance": "updated MEMORY.md with one durable decision",
"content_pipeline_review": "skipped: no stalled drafts",
"seo_opportunity_scan": "flagged one post for refresh",
"link_health_check": "passed",
"weekly_summary": "not due"
}
}I like storing Unix timestamps because they are easy to compare and sort. If you want more detail, add a short result string, a skip reason, or a counter for consecutive failures. Keep it compact so the file stays useful instead of turning into a junk drawer.
When something looks off, this file should answer three questions fast:
- Did the task run?
- What happened?
- When did it last happen?
If you cannot answer those three questions from state alone, the heartbeat system is still too vague.
FAQ
Do active tasks replace cron jobs?
No. They can complement cron, but the active task is the instruction layer. Cron only handles timing. The heartbeat file tells the agent what the timed run should actually do.
Should every check update MEMORY.md?
No. Only durable decisions and reusable lessons belong there. Routine skips, temporary noise, and one-off observations usually belong in the daily log or heartbeat state.
How often should a heartbeat run?
For most agent workflows, every 30 minutes to daily is enough. Pick a cadence that matches the value of the check. More frequent is not automatically better.
What if a task has nothing to do?
Record that it ran and why it skipped. That matters because a clean skip is still a successful check. Silent no-op behavior is what makes systems feel broken.
What is the biggest sign that my HEARTBEAT.md is weak?
If the agent runs but nothing changes, the instructions are too abstract. A strong heartbeat file creates a visible result: a memory update, a short summary, a flagged issue, or a state record.
Final Thoughts
Active tasks work when they are specific enough to produce a decision and disciplined enough to record it. If you are using an AI agent for content or marketing, that is the whole game. Do less. Make each check concrete. Tie it to state. And keep the file boring in the best way possible, because boring is what makes it reliable.
If you want the agent to actually run useful scheduled checks, do not ask it to “stay on top of things.” Tell it exactly what to inspect, what to change, and where to write the proof.
Not Ready to Self-Host? Try ClawTrust
Building agents locally is powerful, but managing infrastructure, security, and scaling takes effort. ClawTrust provides managed OpenClaw hosting — your agents run securely in the cloud with automatic scaling, no DevOps overhead, and 24/7 monitoring.
This post contains affiliate links. If you buy through them, I may earn a small commission at no extra cost to you.
About The Author
Is there a way to trigger the heartbeat check manually without waiting for the scheduled interval? Useful for testing before deploying.
Great question. For HEARTBEAT md Active Tasks Set, I would start with the simplest workable setup and only add complexity if you actually need it. That keeps things easier to troubleshoot and usually gets you to a better result faster.
The distinction between passive checks and active tasks clarified a lot. I had been treating them as the same thing, which explains why some scheduled runs were basically no-ops.
Exactly. A passive check can confirm a condition, but an active task needs a decision point and a follow-up action. If you are scheduling WordPress or marketing work, I would make the action explicit in the task title so the agent knows whether to just observe or actually move something forward.
The four-part active task pattern is solid, especially the part about writing back to state after the run. That is the bit I keep forgetting when I build scheduled checks.
Yep, that write-back step is the thing that keeps the next run honest. Without it, the agent keeps re-evaluating the same state and you get repeated work or false confidence. I usually treat state updates as part of the task, not an optional afterthought.
Nice explanation of why missed heartbeats are usually instruction failures. That felt very true for WordPress maintenance jobs where the agent technically ran but never made a decision.
That is the failure mode I was trying to name. The scheduler can be perfect and still produce nothing useful if the instructions never tell the agent how to decide. A good sanity check is asking, “what changes in the workspace if this task succeeds?”