Support

This page is the triage starting point when a monitor, alert, billing setting, or integration is not behaving the way you expect. The first-check sections below cover the most common failure modes; the operational playbooks at the bottom cover routine procedures (planned maintenance, channel rollout, event-driven hardening).

For browser-push specifics, jump straight to Push troubleshooting.

First checks — missing pings

A run is not appearing on the monitor's timeline:

• Confirm the script is calling the current host — https://api.drumbeats.io/v1/ping/.... URLs under drumbeats.io/docs/... are documentation pages, not Ping API endpoints.
• Confirm the monitor ID or project + slug pair is correct. Copy from the dashboard's URLs panel rather than retyping UUIDs.
• Confirm the monitor is not paused — paused monitors accept pings but do not evaluate them.
• Confirm the script is actually running the ping line. A cron line that uses && between job and ping skips the ping on failure — use ; instead (see Exit codes).
• If using exit-code pings, capture $? into a variable before any other command runs — $? is overwritten by every subsequent command.

First checks — missing alerts

The monitor records events but the notification group is silent:

• Confirm the monitor has a notification group assigned. A monitor with no group never pages.
• Confirm the group contains at least one active channel.
• Click the channel's Test button. If the test arrives, the channel is fine; the issue is upstream.
• For email channels, confirm external recipients completed the verification step. Unverified addresses do not receive alerts.
• For Slack / Discord / Telegram, reconnect the integration if it looks stale — tokens can expire if the workspace re-installs the bot.
• For browser push, walk through Push troubleshooting — push needs both browser and OS permissions.

First checks — unexpected Beats usage

The usage gauge is higher than you expect:

• Count how many events each job sends per run. start + success is 2 Beats per run; adding 3 log pings makes it 5 — see Beats & usage for the table.
• Look for log events firing more often than intended. Routine "step finished" logs add up fast on a high-frequency job.
• Check payload sizes — bytes are metered in 25 KB chunks, so a 30 KB payload costs 3 Beats (1 base + 2 chunks).
• Look for an accidentally high-frequency heartbeat monitor (1m or 30s schedules add up to hundreds of thousands of Beats/month).
• Review the top-projects breakdown in the billing usage view before assuming a pricing bug.

First checks — noisy or false-positive alerts

Alerts are firing more aggressively than the team wants:

• Increase grace_period_seconds on scheduled monitors. A grace period that is too short causes false MISSED alerts on jobs with variable start times.
• Bump failure_tolerance and schedule_tolerance from 1 to 2 (or higher) for jobs with known transient errors.
• Add start pings only when duration tracking is actually needed — start without a matching finish is a hung-run event that pages.
• Pause the monitor during planned maintenance instead of letting it flap. See the playbook below.

Operational playbooks

Planned maintenance

Pause the affected monitor before the maintenance window starts, then resume afterwards. Pings sent during the pause are recorded but do not evaluate — no false alerts.

# Via the REST API
curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/pause \
  -H "X-API-Key: dk_live_<key>"
# … maintenance …
curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/resume \
  -H "X-API-Key: dk_live_<key>"

# Via the REST API
curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/pause \
  -H "X-API-Key: dk_live_<key>"
# … maintenance …
curl -X POST https://api.drumbeats.io/v1/monitors/<monitor-id>/resume \
  -H "X-API-Key: dk_live_<key>"

See REST API — Monitors.

Rolling out a new notification channel

1. Create the channel and send a Test message.
2. Add it to a notification group (alongside any existing channels — multi-channel groups fire in parallel).
3. Attach the group to a low-stakes monitor first.
4. Wait for the next incident or trigger one manually with a failure ping; verify delivery.
5. Roll out to production monitors once you are confident.

Hardening an event-driven job

For queue workers and webhook handlers:

• Always send start with a unique run_id — see Event-driven pings for run_id strategies.
• Use a stable run_id shape across retries — a per-execution UUID is the safest default.
• Always send success or failure at the end, even on early exits — wrap in try / finally.
• Add log events only when they add operational value during triage. Skip them on stable jobs.

Public status

If a customer or stakeholder needs visibility into a specific monitor without dashboard access, publish a Status page.

Contact

For product help, billing questions, or integration support, email support@drumbeats.io. Paid plans receive priority support; this page does not promise a fixed SLA.

For security questions or responsible disclosure, see the Trust Center.