Monitor types

Drumbeats has four monitor types: Cron, Heartbeat, Event-driven, and Uptime. They differ in how Drumbeats decides a job is healthy — by schedule, by interval, by explicit run signals, or by polling an HTTP endpoint from outside.

Pick the type once when you create the monitor. Switching later requires creating a new monitor.

When to use which monitor

The decision splits on two questions:

• Is this an external endpoint we poll, or an internal job we observe? Endpoints get Uptime; jobs get one of the other three.
• Does the job have a predictable cadence? Cron-style schedules use Cron, periodic loops use Heartbeat, on-demand work (queue messages, webhooks) uses Event-driven.

Cron monitor

A Cron monitor watches a job that runs on a fixed cron expression. Drumbeats computes the next scheduled run from your cron expression, your timezone, and the configured grace period, then opens an incident when that run does not report success in time.

Use Cron when your scheduler — system cron, Kubernetes CronJob, Airflow DAG, GitLab schedule — invokes the job on a known timetable.

• Detects: missed runs, failed runs, hung runs (start without finish), duration anomalies.
• Requires: a cron expression and a timezone.
• Reference: Cron monitors.

Heartbeat monitor

A Heartbeat monitor watches a job that pings every N minutes, hours, or days. Drumbeats expects a success ping within each interval plus a grace period and opens an incident when the window passes without one.

Use Heartbeat when the job is a long-lived worker loop ("ping every 5 minutes") rather than a discrete scheduled run.

• Detects: missed intervals, failed intervals, hung runs.
• Requires: an interval string (5m, 1h, 1d, 1w).
• Reference: Heartbeat monitors.

Event-driven monitor

An Event-driven monitor watches jobs that run on demand: queue workers, webhook handlers, manual scripts. Drumbeats does not enforce a schedule — it only reacts to the events your job sends.

Use Event-driven when there is no schedule to fall behind on, only individual runs that succeed, fail, or hang.

• Detects: failed runs (explicit failure ping), hung runs (start without finish in max_duration_seconds).
• Requires: a run_id per execution to correlate start and success / failure pings.
• Reference: Event-driven monitors.

Uptime monitor

An Uptime monitor has Drumbeats poll a public HTTP endpoint from outside on a schedule. Your service does not call Drumbeats — Drumbeats calls your service.

Use Uptime for APIs, marketing sites, status endpoints, or any URL that should respond 2xx from the public internet.

• Detects: non-2xx responses, timeouts, DNS failures, connection refusals.
• Requires: a URL, a check interval, expected status codes.
• Reference: Uptime monitors.

Side-by-side comparison

Where to go next

• Start with Cron monitors if you have a scheduler driving the work.
• Read Event-driven monitors if you are wiring up a queue worker or webhook handler.
• See Incidents to understand what happens after a monitor goes DOWN.
• Compare with other tools in Alternatives.