Monitor Bitbucket Pipelines, and get told why a pipeline failed

Bitbucket Pipelines fails silently in three ways.

Scheduled pipelines and nightly jobs look healthy in Bitbucket until the moment they aren't, and none of the three common failure modes send you a timely, actionable alert.

A success ping at the end of a pipeline catches some failures, but only when the pipeline runs at all. A heartbeat watchdog that expects a ping at your pipeline's cadence catches the rest: build-minute caps, deleted variables, and every other reason a pipeline never fires are all caught as a missing signal.

Setup: one YAML block, about three minutes

No Bitbucket add-on required, no API token, no external agent. The after-script block is a Bitbucket Pipelines built-in: it runs after every step, success or failure.

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

# bitbucket-pipelines.yml
pipelines:
  custom:
    nightly-backup:
      - step:
          name: Run backup
          script:
            - curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<uuid>/start
            - # ... your actual commands ...

          after-script:
            - |
              if [ "$BITBUCKET_EXIT_CODE" = "0" ]; 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 "$BITBUCKET_STEP_NAME failed on $BITBUCKET_BRANCH — build $BITBUCKET_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 steps: the after-script fires and POSTs the failure detail; an incident opens with step name, branch, and build number attached.
• ✓Hung steps: a step that reports a start ping but never completes; the missing completion ping opens an incident after the grace window.
• ✓Pipelines that never start: build-minute cap, deleted variable or environment, or a YAML syntax error. 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 step that fails and immediately recovers within the damping window doesn't page you.

For CI/CD pipelines with native signed-webhook support in LastPing, see GitHub Actions, GitLab CI, and Jenkins. Other platforms: CircleCI, Drone CI, 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 Bitbucket Pipeline fails?

  Add an after-script block to your Bitbucket Pipeline steps that checks BITBUCKET_EXIT_CODE and POSTs failure detail to LastPing's /fail endpoint on failure, and a success curl step at the end of the pipeline. Create a heartbeat monitor in LastPing with your pipeline's schedule so a run that never starts (due to build-minute cap, deleted variable, or runner failure) also opens an incident. Free for individuals, no monitor cap.

• How do I know if a Bitbucket scheduled pipeline stops running?

  Bitbucket Pipelines can stop firing when you've exhausted your monthly build minutes, when a required repository variable or deployment environment is deleted, or when the pipeline configuration YAML has an error that prevents triggering. Bitbucket does not proactively email you when you approach the build-minute limit, and pipelines that fail to start are not "failures" in the notification sense. A LastPing heartbeat monitor expects a ping at your scheduled cadence and opens an incident when the expected signal doesn't arrive, regardless of why: that covers a credit cap, a deleted variable, and any other reason the pipeline never fires.

• What is an after-script in Bitbucket Pipelines, and what is BITBUCKET_EXIT_CODE?

  An after-script block in bitbucket-pipelines.yml runs after the main steps regardless of whether they succeed or fail, similar to a 'finally' block. BITBUCKET_EXIT_CODE is an environment variable Bitbucket Pipelines injects into after-script blocks containing the combined exit code of the preceding script commands. Zero means all commands succeeded; non-zero means at least one failed. Use it to branch between a success ping and a failure POST in a single after-script, so failure detail goes to LastPing only when the pipeline failed.

• Can I attach the Bitbucket Pipeline failure log to the alert?

  Yes. In an after-script step, check BITBUCKET_EXIT_CODE and POST up to 10,000 bytes of plain text to https://ping.lastping.dev/<uuid>/fail: include the pipeline UUID, step name, branch, build number, and any last-log snippet available in the after-script environment. The body is stored on the open incident in LastPing and shown in the console. It is never logged server-side.

• Is Bitbucket Pipelines monitoring free in LastPing?

  Yes. LastPing is free for individuals with no monitor cap. The ping endpoint is plain HTTP: no SDK, no agent. GitHub Actions, GitLab CI, and Jenkins are also supported with their native CI webhook patterns. See how it compares to Healthchecks.io and Cronitor, or read the roundup of free cron monitoring tools.