Monitor Drone CI — and get told why a build failed
Add two
steps
to your
.drone.yml
and set a heartbeat watchdog in LastPing. Every build confirms in; a
build that fails, hangs, or never starts — including cron pipelines
dropped on server restart — opens an incident with failure detail.
Free for individuals, no monitor cap.
Drone CI cron builds fail silently. Here's how.
Drone is lightweight and self-hosted — which means the gaps in its notification model fall on you. Three failure modes go undetected without an external watchdog.
Cron build dropped on restart
Drone's cron scheduler is in-memory. If the server process restarts, crashes, or is redeployed at or near a scheduled fire time, that run is lost. The next run is scheduled as if the previous one never existed.
All runners offline
A build queued while every runner is offline or at capacity waits indefinitely in a pending state. It is not a failure — Drone has no timeout on pending builds by default — so no failure notification fires, ever.
Pipeline conditions filter it out
A cron build that doesn't match a pipeline's
when:
conditions — wrong branch, excluded event — is silently skipped.
The cron log shows "triggered" but the pipeline never ran.
A success ping at the end of a pipeline step catches explicit failures, but only when the build runs at all. The external watchdog covers the rest: if the expected ping doesn't arrive in the grace window, an incident opens — regardless of whether the build crashed, was lost, or never queued.
Setup: two steps in .drone.yml, under three minutes
No Drone plugin marketplace required. A plain
alpine
image with curl
is all that's needed.
Create a heartbeat monitor in LastPing
In the console, create a monitor, choose Heartbeat, and set the period to match your Drone cron schedule. Copy the ping URL.
Add a start step at the top of your pipeline
Insert a step before your main work that pings the
/start endpoint. This arms overrun detection —
if the pipeline starts but never finishes, the missing completion
ping triggers an incident after the grace window.
Add success and failure pings as the final step
Add a final step that always runs (
when: status: [ success, failure ]) and branches
on the build status. The success path sends the ping; the
failure path sends the failure detail as a POST body.
Done — every build now reports in
LastPing receives the start and completion pings. A build that never starts — server restart, offline runner, filtered condition — is caught when the expected completion ping doesn't arrive within the grace window. Alerts go to email, Telegram, Slack, Discord, or a signed webhook.
What this catches
The same durable detection engine as LastPing's cron monitoring — deadlines live in the database, so a restart never misses a due check.
- Failed builds — the failure path fires immediately, POSTing the build name, branch, and build number to the incident.
- Hung builds — a build that reports a start ping but never completes; the missing completion ping opens an incident after the grace window.
- Builds that never start — server restart at cron fire time, all runners offline, or pipeline condition filter. No ping in the expected window → incident.
- Recovery — the next successful completion ping closes the incident and sends a recovery notice. No manual reset.
- Flap protection — a build that fails and immediately recovers within the damping window doesn't page you.
For CI systems with native signed-webhook support in LastPing, see GitHub Actions, GitLab CI, and Jenkins. Other CI platforms using the same ping-step approach: CircleCI, Bitbucket Pipelines, TeamCity. AI agents can self-register their own monitors via MCP.
Questions people ask
Front-loaded answers — the most important fact first.
-
How do I get alerted when a Drone CI build fails?
Add a final step with
when: status: [ success, failure ]that branches on$DRONE_BUILD_STATUSto POST failure detail to LastPing's/failendpoint, or send a success ping. Add a heartbeat monitor with your cron schedule so a build that never starts also opens an incident. Free, no monitor cap. -
Why do Drone CI cron builds stop running?
Drone's cron scheduler is in-memory. A server restart, crash, or redeployment at or near the scheduled fire time drops the run with no re-fire. Additionally, if all runner agents are offline when the build queues, it waits indefinitely with no timeout. A LastPing heartbeat watchdog catches both cases as a missing signal.
-
What image should I use for the ping steps?
alpine/curlis a good default — small image, curl available. If your pipeline already uses an image that includes curl (most debian-based or alpine-based images do), you can add the ping commands to an existing step'scommandslist rather than adding a new step. -
Can I monitor Drone CI pipelines triggered by code push, not just cron?
Yes, but the heartbeat pattern is most useful for time-based (cron) pipelines where absence is a failure signal. For push-triggered pipelines, the success/fail ping steps still fire on every build and open an incident on failure — the watchdog simply doesn't add a "never-started" check unless you set an expected cadence.
-
Is this free?
Yes. LastPing is free for individuals with no monitor cap. See the roundup of free cron monitoring tools, or compare vs Healthchecks.io and vs Cronitor.
Your next dropped cron build is already overdue.
Two steps now beats a post-mortem later. First alert wired up in under three minutes — and LastPing monitors itself the same way.