How Drumbeats works
Follow one ping from your job to the alert in your Slack channel.
Drumbeats answers one question: did the job run and finish on time?
It never connects to your servers. It never reads your logs. It waits for an HTTP request that you promised would arrive, and pages your team when it does not.
# Your job says "I started"
curl "https://api.drumbeats.io/v1/ping/<monitor-id>/start?run_id=nightly-8891"
# ... work happens ...
# Your job says "I finished cleanly"
curl "https://api.drumbeats.io/v1/ping/<monitor-id>/success?run_id=nightly-8891"# Your job says "I started"
curl "https://api.drumbeats.io/v1/ping/<monitor-id>/start?run_id=nightly-8891"
# ... work happens ...
# Your job says "I finished cleanly"
curl "https://api.drumbeats.io/v1/ping/<monitor-id>/success?run_id=nightly-8891"That is the entire contract between your infrastructure and Drumbeats.
Follow one ping through the system#
- You create a monitor and pick its type: Cron, Heartbeat, Event-driven, or Uptime.
- Your job sends an HTTP request to
https://api.drumbeats.io/v1/ping/<monitor-id>/<event>. - Drumbeats records the event on the run timeline and updates the monitor's state.
- Drumbeats watches the clock against the run you promised. When the deadline plus the grace period passes with no
success, or afailureping arrives, it opens an incident. - The incident pages every channel in every notification group attached to the monitor.
- A later
successping resolves the incident, flips the monitor back to UP, and sends a recovery message.
Uptime monitors invert step 2. Drumbeats requests your URL on a schedule instead of waiting for your job to call in. Everything from step 3 onward is identical.
What Drumbeats stores per ping#
| Field | Where it comes from |
|---|---|
| Event name | The URL suffix: start, success, failure, log, or an exit code |
| Timestamp | When the ping API received the request, not when your job sent it |
run_id | The query parameter or POST body field you supplied |
| Duration | Computed from start to finish when both share a run_id, or taken from duration_ms if you send it |
| Payload | The POST body, when there is one |
| Source IP and user agent | The request itself |
Each monitor keeps its most recent pings and drops older ones. The default is 200 per monitor, adjustable between 10 and 1000 with retention_count.
How Drumbeats decides a job is late#
Cron monitors compute the next expected run from your cron expression and timezone. Heartbeat and Uptime monitors sit on a fixed interval grid anchored at monitor creation. Event-driven monitors have no deadline at all, so they can never be late, only failed or hung.
The grace period is the slack you allow past that deadline. It defaults to 300 seconds. Only when the deadline plus the grace period passes without a success does the run count as missed.
Missed runs and failures do not page immediately by default. schedule_tolerance and failure_tolerance set how many in a row it takes, and both default to 1, so the first one pages. Raise them for jobs with known transient failures.
What you do not have to install#
There is no agent, no daemon, and no SDK. Any language that can make an HTTP request can talk to Drumbeats: curl, fetch, requests, net/http, file_get_contents. Ping endpoints take no authentication header, so the monitor ID in the URL is the credential.
Billing follows usage rather than seats. Idle monitors cost nothing and every plan includes unlimited team members. Beats and usage has the formula.
Next#
Quickstart runs this whole loop end to end in five minutes. Monitor types picks the right type for each workload. Ping API is the HTTP reference the model rides on.