Monitor Bitbucket Pipelines — and get told why a pipeline failed
Add an
after-script
block and a success ping to your
bitbucket-pipelines.yml,
plus a heartbeat watchdog in LastPing. Every pipeline run confirms in; a
run that fails, hangs, or never starts opens an incident with failure
detail. Free for individuals, no monitor cap.
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.
Build-minute cap hit
Bitbucket Cloud free plans include a fixed number of build minutes per month. When the cap is hit, new pipelines queue and never start. No email to the pipeline owner. Your nightly backup simply stops.
Deleted variable or environment
A pipeline that references a repository variable or deployment environment that was renamed, deleted, or access-revoked fails at the first step that needs it — often silently for scheduled runs because the notification only goes to the committer (who isn't one).
Hung runner or step
A pipeline step that hangs — a frozen network call, an infinite retry loop, an SSH connection that never times out — runs until Bitbucket's step timeout kills it hours later. Nobody is paged while it waits.
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.
Create a heartbeat monitor in LastPing
In the console, create a monitor, choose Heartbeat, and set the period to match your pipeline schedule. Copy the ping URL.
Add a start ping at the top of your pipeline step
Add a script entry as the first command in your
relevant pipeline step. This arms overrun detection — if the step
starts but never finishes, the missing completion ping opens an
incident.
Add a success ping and failure detail with after-script
The after-script block runs regardless of step
outcome. Check BITBUCKET_EXIT_CODE to send either
a success ping or a failure POST with context. Up to
64 KB is stored on the open incident.
Done — every pipeline run now reports in
LastPing receives the start ping, then either a success ping or a fail POST with context. A run that never starts — because of a build-minute cap or any other reason — is caught as a missing signal when the watchdog deadline passes. 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 steps — the
after-scriptfires 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?
Use an
after-scriptblock that checksBITBUCKET_EXIT_CODEand POSTs failure detail to LastPing's/failendpoint. Add a heartbeat monitor with your schedule so a run that never starts also opens an incident. Free, no monitor cap. -
How do I know when the Bitbucket build-minute cap is hit?
Bitbucket does not proactively email you when you approach the 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 signal doesn't arrive — that covers a credit cap, a deleted variable, and any other reason the pipeline never fires.
-
What is BITBUCKET_EXIT_CODE?
BITBUCKET_EXIT_CODEis an environment variable Bitbucket Pipelines injects intoafter-scriptblocks containing the combined exit code of the precedingscriptcommands. 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 singleafter-script. -
Can I attach the pipeline failure log to the alert?
Yes. POST up to 64 KB of plain text to
https://ping.lastping.dev/<uuid>/fail— include the step name, branch, build number, and any last-log snippet available in theafter-scriptenvironment. The body is stored on the open incident and shown in the console. -
Is this free?
Yes. LastPing is free for individuals with no monitor cap. See how it compares to Healthchecks.io and Cronitor, or read the roundup of free cron monitoring tools.
Your next silent pipeline failure is already scheduled.
One YAML block now beats a post-mortem later. First alert wired up in about three minutes — and LastPing monitors itself the same way.