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.
Your assistant can do this for you
Monitor my CircleCI pipelines with LastPing
On this page
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 Cron job, and set the schedule to match your pipeline's schedule (e.g. daily, with a 30-minute grace window). Copy the ping URL shown on screen.
https://ping.lastping.dev/<uuid>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.
# .circleci/config.yml
jobs:
nightly-backup:
steps:
- run:
name: Arm LastPing watchdog
command: curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<uuid>/startAdd 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 Slack, Discord, Telegram,
ntfy, Pushover, Microsoft Teams, Google Chat or a signed
webhook if you add them.
- run:
name: Signal success to LastPing
command: curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<uuid>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 10,000 bytes are stored on the
open incident and shown in the console, so the alert doesn't just
say "it broke," it shows where.
- run:
name: Report failure to LastPing
when: on_fail
command: |
curl -fsS -X POST -H "Content-Type: text/plain" \
--data "$CIRCLE_JOB failed on $CIRCLE_BRANCH — build $CIRCLE_BUILD_NUM" \
"https://ping.lastping.dev/<uuid>/fail"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 CircleCI 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 (due to resource class exhaustion, credit cap, or a configuration error) also opens an incident. Free for individuals, no monitor cap. -
How do I know if a CircleCI scheduled pipeline stops running?
CircleCI scheduled pipelines stop silently when your organisation's credit balance reaches zero, when a required context or environment variable is deleted, or when an admin disables the pipeline. A dead-man's-switch heartbeat monitor in LastPing expects a ping at your pipeline's cadence and opens an incident when the expected signal doesn't arrive, regardless of the reason.
-
What happens when a CircleCI executor resource class is exhausted?
When all available executors for a resource class are busy and no more can be allocated, your job queues and waits. It is not a failure, so no failure notification is sent, and your job may wait indefinitely. 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 get a CircleCI failure reason on the alert?
Yes. Add a
when: on_failstep at the end of the job that POSTs up to 10,000 bytes of plain text (job name, step, branch, build number, last log lines and any other relevant context) tohttps://ping.lastping.dev/<uuid>/fail. The body is stored on the open incident and shown in the LastPing console, so the alert doesn't just say "it broke," it shows where. It is never logged server-side. -
Is CircleCI monitoring free in LastPing?
Yes. LastPing is free for individuals with no monitor cap. The ping endpoint is plain HTTP: no SDK, no agent, no dependencies beyond curl. 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.