Drumbeats Documentation
Drumbeats watches your cron jobs, queue workers, and HTTP endpoints, and pages your team when one stops behaving.
Add one line to the end of your job:
curl https://api.drumbeats.io/v1/ping/<monitor-id>/successcurl https://api.drumbeats.io/v1/ping/<monitor-id>/successThat is the whole integration. No SDK, no agent, no API key on the ping path. Drumbeats now knows when that job last finished.
What happens when it breaks#
Drumbeats watches the clock, not your server. When the ping you promised does not arrive, the monitor flips to DOWN and Drumbeats opens an incident.
| Failure | What Drumbeats sees | Incident event |
|---|---|---|
| The job never ran | No ping by the scheduled time plus the grace period | MISSED |
| The job ran and failed | A failure ping, or a non-zero exit code | FAILED |
| The job hung | A start ping with no finish inside max_duration_seconds | FAILED |
| The job finished late | The finish ping arrives past max_duration_seconds | DURATION_HIGH |
| Your HTTP endpoint stopped answering | Three failed checks in a row | FAILED |
How you get alerted#
The incident pages a notification group. Every channel in that group fires in parallel: Slack, email, Microsoft Teams, Telegram, Discord, PagerDuty, browser push, or a webhook. The message carries the monitor name, the incident event, the timestamp, and a link straight to the incident.
The next success ping resolves the incident, flips the monitor back to UP, and sends a recovery message with the outage duration.
Quickstart walks the whole loop, including a test failure you can trigger by hand. It takes about five minutes.
Pick a monitor type#
Choose the type that matches what you are watching. The rest of the docs assume you have already chosen.
| What you are watching | Monitor type | Reference |
|---|---|---|
| A job on a fixed schedule (cron, Airflow, Kubernetes CronJob) | Cron | Cron monitors |
| A worker loop that ticks every N minutes | Heartbeat | Heartbeat monitors |
| An on-demand task (queue message, webhook, manual script) | Event-driven | Event-driven monitors |
| A public HTTP endpoint (API, website, health check) | Uptime | Uptime monitors |
Monitor types walks the decision tree if none of those is an obvious match.
Wire it into your stack#
Every monitor type works with one HTTP request from your job.
| Stack | Guide |
|---|---|
| Node.js and TypeScript | Node.js |
| Python | Python |
| Go | Go |
| PHP | PHP |
| Shell and Bash | Shell |
| GitHub Actions | GitHub Actions |
| Kubernetes CronJobs | Kubernetes |
| Claude, Cursor, VS Code | AI agent |
Read the API reference#
| Reference | What it covers | Auth |
|---|---|---|
| Ping API | Every endpoint your job calls: events, payloads, exit codes | None. The monitor ID in the URL is the credential |
| REST API | Monitors, incidents, projects, notification channels and groups | X-API-Key header |
| Notifications | Channels, routing groups, alert thresholds | Dashboard |
| Webhook payloads | Exact JSON body Drumbeats POSTs on DOWN and RECOVERY | Yours to set |
| Incidents | The OPEN to ACKNOWLEDGED to RESOLVED lifecycle | Dashboard or REST API |
| Status pages | Public health pages your customers can subscribe to | None for readers |
Operate Drumbeats#
| Task | Page |
|---|---|
| Set up projects, members, roles, and 2FA | Workspace setup |
| Understand what you are billed for | Beats and usage |
| Handle invoices, plan changes, failed payments | Billing lifecycle |
| Add retries, timeouts, and ping isolation | Production hardening |
| Diagnose a monitor that is not behaving | Support |
| Review security posture before rollout | Security |
Understand the model#
How Drumbeats works traces one ping from your job to the alert in your Slack channel. Alternatives compares Drumbeats to Cronitor, Healthchecks.io, and Dead Man's Snitch if you are still evaluating.