Support

Start with the symptom.

Browser push has its own page: push troubleshooting.

Pings are not arriving#

Work down this list. Each step rules out one layer.

1. Check the host. Pings go to https://api.drumbeats.io/v1/ping/…. A URL under drumbeats.io/docs/… is a documentation page and will never record anything.
2. Re-copy the monitor ID. Copy it from the dashboard's URLs panel rather than retyping. A wrong UUID returns 404 with code: MONITOR_NOT_FOUND, and the monitor stays silent until it misses.
3. Check whether the monitor is paused. Paused monitors accept pings without evaluating them. The response is 200 with code: MONITOR_PAUSED.
4. Check the ping line actually runs. command && curl .../success skips the ping whenever the command fails. Use ; or branch on both outcomes.
5. Check $? was captured immediately. Every command overwrites it, including echo. EXIT=$? has to be the very next line.
6. Run the curl by hand from the same host. If it works from your laptop but not from the server, you are looking at egress rules, not Drumbeats.

Read the response body rather than only the status. Every ping error carries a machine-readable code that names the cause. See the ping API.

Alerts are not arriving#

The pings land and incidents open, but nothing reaches anyone.

1. Check the monitor has a notification group. A monitor with no group and no direct channel pages nobody, and nothing in its state says so. This is the most common cause by a wide margin.
2. Check the group has channels in it. An empty group behaves identically to no group.
3. Click Test on the channel. If the test arrives, the channel works and the problem is the routing above it. If it does not, the problem is the channel.
4. For email, confirm the recipient verified. External addresses receive nothing until they click the confirmation, and unverified ones expire.
5. For Slack, Discord, or Telegram, reconnect. Tokens go stale when a workspace reinstalls the app or the bot is removed from a group. Neither notifies Drumbeats.
6. Check whether surge protection is active. After alert_surge_threshold consecutive alerts, paging pauses for one hour while incidents keep recording. alerts_paused_until on the monitor holds the timestamp.
7. Check alert_enabled. Set to false, the monitor records incidents and never pages.

Usage is higher than expected#

1. Count the events per run. start plus success is 2 beats. Adding three log pings makes it 5.
2. Look for payloads on successful runs. Every payload costs at least one extra beat. Attaching one to every success, not just failures, doubles that monitor's cost.
3. Check payload sizes. Charged in 25 KB chunks on the size you sent, including bytes truncation later discarded. A 30 KB payload is 3 beats.
4. Look for a high-frequency monitor. A 1m heartbeat with start and success is 86,400 beats a month on its own.
5. Check for a monitor that has been down a while. Failing uptime checks retry twice, and each retry burns a beat, so a down URL costs three times its healthy rate.
6. Read the top-projects breakdown in the billing usage view before assuming a billing bug.

Beats and usage has the formula and the worked examples.

Alerts are too noisy#

1. Widen grace_period_seconds. A short grace period on a job with variable start time is the leading cause of false MISSED alerts. The default is 300 seconds and going below it is rarely worth the noise.
2. Raise failure_tolerance on jobs with known transient errors. Two absorbs a single blip. Understand the cost: on a daily job, tolerance of 2 means you learn about a real failure a day late.
3. Check you are not sending start without a reliable finish. A start with no matching finish becomes a hung-run alert. Adding start to a job you do not always finish reporting creates alerts you did not have before.
4. Pause during planned maintenance rather than letting the monitor flap.

curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/pause \
  -H "X-API-Key: dk_live_<key>"

# maintenance happens

curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/resume \
  -H "X-API-Key: dk_live_<key>"

curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/pause \
  -H "X-API-Key: dk_live_<key>"

# maintenance happens

curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/resume \
  -H "X-API-Key: dk_live_<key>"

Check your wiring before you need it#

GET /v1/monitors/<monitor-id>/warnings

GET /v1/monitors/<monitor-id>/warnings

Returns advisory notes about how the monitor is actually being used, computed over the last seven days: missing run_id, missing start pings on event-driven monitors, and similar. These are the mistakes that leave a monitor looking healthy while it cannot detect anything.

Worth running in CI against your production monitors.

Roll out a new channel safely#

1. Create it and send a test.
2. Add it to a group alongside channels you already trust.
3. Attach that group to one low-stakes monitor.
4. Trigger a real failure with curl .../failure and confirm delivery.
5. Roll out to the monitors that matter.

Contact#

Email support@drumbeats.io for product, billing, or integration help. Paid plans get priority. There is no fixed response-time SLA.

For security questions or responsible disclosure, see the trust center.

If a customer or stakeholder needs visibility without a dashboard account, publish a status page.