Monitor Drone CI, and get told why a build failed

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.

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.

https://ping.lastping.dev/<uuid>

# .drone.yml
kind: pipeline
type: docker
name: nightly-backup

steps:
  - name: arm-watchdog
    image: alpine/curl
    commands:
      - curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<uuid>/start

  - name: notify-lastping
    image: alpine/curl
    when:
      status: [ success, failure ]
    commands:
      - |
        if [ "$DRONE_BUILD_STATUS" = "success" ]; then
          curl -fsS -m 10 --retry 3 -o /dev/null \
            "https://ping.lastping.dev/<uuid>"
        else
          curl -fsS -m 10 -X POST -H "Content-Type: text/plain" \
            --data "$DRONE_REPO_NAME / $DRONE_STAGE_NAME failed on $DRONE_BRANCH — build $DRONE_BUILD_NUMBER" \
            "https://ping.lastping.dev/<uuid>/fail"
        fi

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 pipeline step with when: status: [ success, failure ] that branches on $DRONE_BUILD_STATUS to POST failure detail to LastPing's /fail endpoint, or send a success ping. Create a heartbeat monitor in LastPing with your cron schedule so a build that never starts (because the server restarted, the runner disconnected, or the cron trigger misfired) also opens an incident. Free for individuals, no monitor cap.

• Why do Drone CI cron builds stop running?

  Drone's cron scheduler is an in-memory service on the server process. If the Drone server restarts, crashes, or is redeployed at or near a scheduled run time, that run is dropped and does not re-fire. Additionally, if all runner agents are offline when the build queues, it waits indefinitely with no timeout, and a pending build can be lost. A LastPing heartbeat monitor expects a ping at your cron cadence and opens an incident when the signal doesn't arrive, regardless of whether the server crashed or the pipeline simply failed.

• Does Drone CI have a built-in dead-man's-switch?

  No. Drone notifies on build failure or success, but it cannot notify when a build never starts, because the notification originates from within the build process itself. An external watchdog like LastPing closes this gap by expecting a ping at your scheduled cadence and alerting on absence.

• How do I add conditional steps in Drone CI?

  Drone CI steps support a when condition that can filter on status: [ success ] or status: [ failure ]. A step with when: status: [ failure ] only runs when a preceding step has failed, making it ideal for failure-notification steps that POST detail to LastPing's /fail endpoint.

• What image should I use for the ping steps?

  alpine/curl is 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's commands list 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 Drone CI monitoring free in LastPing?

  Yes. LastPing is free for individuals with no monitor cap. GitHub Actions, GitLab CI, and Jenkins also have native CI webhook support. CircleCI, Bitbucket Pipelines, and TeamCity use the same ping-step approach as Drone CI. See the roundup of free cron monitoring tools, or compare vs Healthchecks.io and vs Cronitor.