Event-Driven Automation

Type: Automation architecture pattern

Definition

Event-Driven Automation reacts to state changes in real-time rather than running on a fixed schedule. An event source (file system, network, sensor, external system) emits an event, a detector identifies it, a decision logic determines the response, and an action handler executes. Examples: home automation (motion detected → lights turn on), system monitoring (error log detected → alert dispatched), and heartbeat monitoring (cron tick → health check → alert if problem found). The pattern is about reacting to change, not running on a timer.

How It Works

The event source is where state changes happen: a file being created, a sensor triggering, a log entry being written, a webhook being received. The source emits events — it doesn't know what will handle them.

The detector monitors the source and identifies relevant events. In OpenClaw, cron jobs often serve as the detector — every 2 hours, a heartbeat job runs and checks logs for ERROR entries, checks disk usage, verifies the Gateway is running. The cron is the heartbeat (time-based event), and the detector logic in the heartbeat script is what identifies problems.

The decision logic determines what to do based on the detected event. If disk > 80% → WARNING alert. If ERROR in logs → CRITICAL alert. If everything is normal → proactive silence (no message sent). Decision logic should be explicit and rule-based, not vague.

The action handler executes the response: send a WhatsApp message, write to a log, trigger a backup, turn on lights. In OpenClaw, the message tool handles alert dispatching, and the exec tool runs remediation scripts.

Real systems combine patterns: Event-Driven for heartbeat monitoring, Simple Pipeline for the health check itself, Hub and Spoke for alert routing to appropriate channels.

Key Properties

  • Event source → detector → decision → action — four components reacting to state change
  • Real-time reaction — responds immediately when events occur, not on a schedule
  • Proactive silence design — only alert when something needs attention; no "system normal" messages
  • Cron as event source — time-based checks (heartbeat every 2 hours) serve as event triggers
  • Three-tier severity — CRITICAL (immediate alert), WARNING (daytime-only alert), INFO (log only)
  • Decision logic is explicit — rule-based conditions (disk > 80%, ERROR in logs) determine action
  • simple-pipeline — individual actions in the event-driven chain often implement Simple Pipeline
  • hub-and-spoke — alert routing uses Hub and Spoke (alert level → appropriate channel handler)
  • cron-heartbeat — cron-driven heartbeat is the most common event source in OpenClaw

Source Chapters