Monitor CircleCI — and get told why a pipeline failed
Add two run
steps to your CircleCI config.yml
and set a matching heartbeat in LastPing. Every pipeline run confirms in;
a run that fails, hangs, never starts, or silently stops due to credit
exhaustion opens an incident, alerts you where you work, and shows you
the failure detail. Free for individuals, no monitor cap.
CircleCI pipelines fail silently. Three ways.
Scheduled pipelines, nightly builds, and maintenance jobs look healthy in the UI right until the moment they aren't — and none of the three common failure modes send you a useful alert.
Credit or plan limit hit
When your organisation's CircleCI credit balance reaches zero, or a usage-based cap is hit, new jobs stop queuing and scheduled pipelines stop firing. No email to the pipeline owner. The dashboard shows the last successful run, frozen in time.
Executor resource class exhausted
A job waiting for an executor of a specific resource class —
medium,
large,
or a self-hosted runner — queues indefinitely. It is not a failure,
so no failure notification fires. Your nightly backup just waits.
Context or environment variable deleted
A pipeline that depends on a context or environment variable fails immediately at the "Spin up environment" step when that context is deleted or access is revoked. The run shows as failed — but only if you're watching. Scheduled runs notify nobody by default.
Adding a curl success ping at the end of a job catches
some of this, but only when the job runs at all. The full solution
is a heartbeat monitor that expects a ping on your pipeline's
schedule — so silence is an alert, not a gap in the data. Combined, the
two patterns together catch all three failure modes.
Setup: two steps in config.yml, about three minutes
No CircleCI orb required, no API token, no external agent. Plain
curl
steps and an external watchdog that lives outside CircleCI.
Create a heartbeat monitor in LastPing
In the console, create a monitor, choose Heartbeat, and set the period to match your pipeline's schedule (e.g. 86400 s for daily with a 1800 s grace window). Copy the ping URL shown on screen.
Add a start ping at the top of your job
In your .circleci/config.yml, add a
run step as the first step of the job. This arms
overrun detection — if the job starts but never finishes,
the missing completion ping opens an incident.
Add a success ping as the last step
At the end of the job's steps, add another run to
signal success. LastPing receives it and resets the watchdog.
Alerts go to email by default — and to Telegram, Slack, Discord,
or a signed webhook if you add them.
Optional: attach failure detail to the incident
Add a when: on_fail step that POSTs the failure
context — job name, step, branch — as a plain-text body to the
/fail endpoint. Up to 64 KB is stored on the
open incident and shown in the console, so the alert doesn't just
say "it broke," it shows where.
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 jobs — the
on_failstep fires immediately, POST-ing the failure detail; an incident opens with context attached. - Hung jobs — a job that reports a start ping but never completes; the missing completion ping opens an incident after the grace window.
- Jobs that never start — credit exhaustion, resource class unavailability, deleted contexts, or scheduled pipeline disabled. 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 job that fails and immediately recovers within the damping window doesn't page you.
For CI/CD pipelines with native webhook support — where LastPing listens to platform events rather than steps within a run — see GitHub Actions, GitLab CI, and Jenkins. For cron jobs, Kubernetes jobs, and systemd timers, see the monitoring guides index. AI agents can also 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 CircleCI workflow fails?
Add a
when: on_failstep at the end of your job that POSTs to LastPing's/failendpoint, and a success ping step on normal completion. Create a heartbeat monitor in LastPing with your pipeline's cadence so a run that never starts also opens an incident. Free, no monitor cap. -
How do I know if a CircleCI scheduled pipeline stops running?
CircleCI scheduled pipelines stop when your organisation's credit balance reaches zero, when a required context is deleted, or when an admin disables the pipeline. A LastPing heartbeat monitor expects a ping at your pipeline's cadence and opens an incident when the signal doesn't arrive — regardless of the reason.
-
What happens when a CircleCI resource class is exhausted?
Jobs queue and wait without sending a failure notification. A LastPing heartbeat monitor set to expect a completion ping within a grace window catches this because the expected ping never arrives. You'll get an alert before the stuck job has been waiting for hours.
-
Can I attach the failure reason to the alert?
Yes. The
when: on_failstep can POST up to 64 KB of plain text — job name, branch, build number, last log lines — tohttps://ping.lastping.dev/<uuid>/fail. The body is stored on the open incident and shown in the console. It is never logged server-side. -
Is this free?
Yes. LastPing is free for individuals with no monitor cap. See how LastPing compares to Healthchecks.io and Cronitor, or read the roundup of free cron monitoring tools. GitHub Actions, GitLab CI, and Jenkins are also supported.
Your next silent pipeline failure is already scheduled.
Two curl steps now beat a post-mortem later. First alert wired up in about three minutes — and LastPing monitors itself the same way.