Reference

Beats and usage

Work out what your monitoring will cost before the invoice tells you.

beats per ping = 1 + ceil(payload_bytes / 25,000)

beats per ping = 1 + ceil(payload_bytes / 25,000)

A ping with no body costs exactly 1 beat. A ping with any body at all costs at least 2.

Usage is owner-wide. Included beats are shared across every project the billing owner controls. Prices and allowances are on drumbeats.io/pricing.

What a payload costs#

Payload	Beats
None	1
1 KB	2
10 KB	2
25 KB	2
26 KB	3
50 KB	3
100 KB	5
1 MB	41

What counts as a ping#

Every event costs 1 base beat: start, success, failure, log, and exit-code pings alike. Uptime checks also cost 1 beat per check, per location.

Pattern	Pings per run	Base beats per run
Success only	1	1
Start and success	2	2
Start, success, one log	3	3
Start and failure	2	2
Start, three logs, success	5	5

Work out your monthly total#

Count how many times each job runs per day.
Count the events it sends per run.
Multiply runs by events by days.
Add ceil(payload_bytes / 25000) per ping that carries a body.

Four worked examples, base beats only:

100 monitors, daily, success only
100 × 1 × 30                      = 3,000 beats/month

100 monitors, hourly, start + success
100 × 2 × 24 × 30                 = 144,000 beats/month

100 monitors, every 5 min, start + success
100 × 2 × 12 × 24 × 30            = 1,728,000 beats/month

50 monitors, hourly, start + success + 2 logs
50 × 4 × 24 × 30                  = 144,000 beats/month

100 monitors, daily, success only
100 × 1 × 30                      = 3,000 beats/month

100 monitors, hourly, start + success
100 × 2 × 24 × 30                 = 144,000 beats/month

100 monitors, every 5 min, start + success
100 × 2 × 12 × 24 × 30            = 1,728,000 beats/month

50 monitors, hourly, start + success + 2 logs
50 × 4 × 24 × 30                  = 144,000 beats/month

The pricing calculator does this interactively.

What happens when you go over#

Drumbeats applies graduated bands rather than cutting you off at 100%. Free and Pro always run under these bands. Business runs under them whenever PAYG is off.

Usage	What happens
0 to 100%	Normal
100 to 110%	Warning. Everything still works, a banner appears
110 to 130%	Degraded. Pings are recorded, payloads are dropped. Monitors still flip and alert
Over 130%	Rejected. Pings return `429` with `code: QUOTA_EXCEEDED` and are not recorded

Detection survives the degraded band. You lose payloads, which hurts triage, not the alert itself.

The rejected band is different. Pings are not recorded at all, so a scheduled monitor will start reporting MISSED for jobs that ran perfectly well. Usage exhaustion looks exactly like an outage.

On Business with PAYG enabled, overage bills per beat up to your spending limit instead of degrading. See billing lifecycle.

Keep usage where you expect it#

Send payloads on failures, not successes. A successful run rarely needs a body, and every one you attach at least doubles that ping.

Trim before you send. tail -n 100 on stderr rather than the whole log. Truncate in your own code so you keep the end of a stack trace, since Drumbeats truncates from the front.

Use log pings where the phase matters. They earn their keep on a multi-phase job you are debugging. On a stable job they are pure cost.

Add start where hangs are possible. It is one extra beat per run and it is what makes hung-run detection and duration tracking work at all. Worth it on anything that can stall.

Check the arithmetic before enabling a high-frequency monitor. A 30-second heartbeat with start and success is 2 × 120 × 24 × 30 = 172,800 beats a month for one monitor.

Next#

Payloads for storage tiers and truncation. Billing lifecycle for PAYG and plan changes. Pricing for included beats per plan.