home / skills / openclaw / skills / heartbeat

heartbeat skill

/skills/ivangdavila/heartbeat

This skill auto-manages wake times by learning patterns, balancing responsiveness and efficiency to optimize monitoring and task execution.

npx playbooks add skill openclaw/skills --skill heartbeat

Review the files below or copy the command above to add this skill to your agents.

Files (10)
SKILL.md
4.5 KB
---
name: Heartbeat
slug: heartbeat
version: 1.0.1
homepage: https://clawic.com/skills/heartbeat
description: Design better OpenClaw HEARTBEAT.md files with adaptive cadence, safe checks, and cron handoffs for precise schedules.
changelog: "Refined heartbeat guidance with a production template, QA checklist, and cron handoff rules for safer proactive monitoring."
metadata: {"clawdbot":{"emoji":"💓","requires":{"bins":[]},"os":["linux","darwin","win32"]}}
---

# Heartbeat 💓

Build reliable heartbeat playbooks for OpenClaw agents without noisy checks, missed signals, or runaway costs.

## Setup

On first use, follow `setup.md` to capture timezone, active hours, precision needs, and risk tolerance.

## When to Use

User wants a better heartbeat file in OpenClaw. Agent audits current heartbeat behavior, designs a safer file, and tunes intervals using real workflow constraints.

Use this for adaptive monitoring, proactive check-ins, and hybrid heartbeat plus cron strategies.

## Architecture

Memory lives in `~/heartbeat/`. See `memory-template.md` for the structure and fields.

```text
~/heartbeat/
├── memory.md              # Preferences, cadence profile, and last tuning decisions
├── drafts/                # Candidate heartbeat variants
└── snapshots/             # Previous heartbeat versions for rollback
```

## Quick Reference

| Topic | File |
|-------|------|
| Setup interview | `setup.md` |
| Memory schema | `memory-template.md` |
| Production heartbeat template | `heartbeat-template.md` |
| Practical heartbeat use cases | `use-cases.md` |
| Interval strategy reference | `intervals.md` |
| Trigger strategy reference | `triggers.md` |
| Validation checklist before shipping | `qa-checklist.md` |
| Internet research sources | `sources.md` |

## Core Rules

### 1. Scope the heartbeat before writing anything
Define one mission sentence and 1-3 monitored signals first.

If scope is broad, split into explicit sections (`critical`, `important`, `nice-to-have`) and only automate the first two.

### 2. Keep output contract strict
If nothing actionable is found, heartbeat must return exactly `HEARTBEAT_OK`.

Do not emit summaries on empty cycles. This prevents noisy loops and keeps heartbeat cheap.

### 3. Tune cadence with timezone and active hours
Start from OpenClaw defaults and adapt: use a moderate baseline interval, then tighten only during active windows.

Always encode timezone and active hours in the heartbeat file to avoid waking during sleep hours.

### 4. Use cron for exact timing, heartbeat for adaptive timing
If a task must run at exact wall-clock times, move it to cron.

If a task should react to changing context or event probability, keep it in heartbeat.

### 5. Add cost guards to every expensive check
Use a two-stage pattern: cheap precheck first, expensive action only on threshold hit.

Never call paid APIs on every heartbeat cycle unless the user explicitly accepts the cost.

### 6. Define escalation and cooldown rules
Each alert condition must have trigger threshold, escalation route, and cooldown period.

No escalation path means no alert. No cooldown means likely alert spam.

### 7. Validate with dry runs and rollback path
Before finalizing, run at least one dry simulation against the checklist in `qa-checklist.md`.

Keep a snapshot of the previous heartbeat so the user can rollback in one step.

## Common Traps

- Polling everything every cycle -> high token/API burn with low signal quality.
- Using heartbeat for exact 09:00 jobs -> drift and missed exact-time expectations.
- Missing timezone in heartbeat config -> notifications at the wrong local time.
- No active-hours filter -> overnight wakeups and user fatigue.
- No `HEARTBEAT_OK` fallback -> verbose no-op loops.
- No cooldown on alerts -> duplicate escalations during noisy incidents.

## Security & Privacy

Data that stays local:
- Heartbeat preferences and tuning notes in `~/heartbeat/`
- Draft and snapshot files for heartbeat definitions

This skill does NOT:
- Require credentials by default
- Trigger external APIs without user-approved instructions
- Edit unrelated files outside the heartbeat workflow

## Related Skills
Install with `clawhub install <slug>` if user confirms:

- `schedule` - Scheduling patterns for recurring workflows
- `monitoring` - Monitoring strategies and alert design
- `alerts` - Alert routing and escalation hygiene
- `workflow` - Multi-step workflow orchestration
- `copilot` - Proactive assistant patterns with controlled autonomy

## Feedback

- If useful: `clawhub star heartbeat`
- Stay updated: `clawhub sync`

Overview

This skill auto-learns when to wake. It balances responsiveness and efficiency by starting conservatively, observing outcomes, proposing adjustments, and only storing confirmed rules. Over time it grows autonomy while honoring explicit user limits and context signals.

How this skill works

On each wake the skill runs a checklist of monitors, records whether the wake was useful, and checks event triggers. It tracks hit-rate per category, detects patterns after multiple observations, prompts the user to confirm suggested interval changes, and then stores confirmed rules. Hard rules (like explicit ignores and night hours) are always respected and context changes cause re-evaluation.

When to use it

  • When you want an assistant that reduces noisy checks while staying responsive
  • For monitoring streams with variable importance (email, deploys, calendar)
  • When you need adaptive polling that learns from feedback
  • To minimize battery or compute usage by extending checks when low value is detected
  • When you require explicit user control over which checks are suppressed

Best practices

  • Start with conservative defaults (default to idle) and let the skill gather at least 3 data points before changing behavior
  • Provide clear feedback phrases (e.g., 'Don't bug me about X', 'Good catch') so learning signals remain accurate
  • Confirm suggested changes—only accept automatic rule creation after explicit user consent
  • Define emergency exceptions so critical alerts bypass dormant rules
  • Keep quiet and trigger lists explicit to avoid accidental suppression of important checks

Example use cases

  • Email triage: learn which senders/topics are worth frequent checks and reduce checks for low-value threads
  • Deployment monitoring: watch active deploys at short intervals, then demote to watching/idle after completion
  • Calendar reminders: increase checks as an event approaches, otherwise stay idle
  • Social mentions: start sparse, then increase frequency for high-value accounts
  • Background backups: run less often if no changes detected since last wake

FAQ

How does it decide when to change intervals?

It tracks usefulness (hit rate) per category; after three or more wakes that form a pattern it suggests an optimal interval and asks for confirmation before saving it.

What protections prevent unwanted wakes at night?

Night hours default to dormant and the skill will not wake except for explicitly defined emergencies or user-approved exceptions.