Monitor GitLab CI — and get told why a pipeline failed
Point one Pipeline events
webhook from your project at LastPing — zero changes to your
.gitlab-ci.yml.
Every pipeline reports in; one that fails, stalls waiting for a runner,
or never starts opens an incident, alerts you where you work, and
deep-links to the pipeline. Free for individuals, no monitor cap.
Scheduled pipelines fail silently. By design.
If you run a nightly build, a scraper, a DB backup, or a cert renewal on a GitLab pipeline schedule, three failure modes are waiting for you — and GitLab tells you about none of them reliably.
The silently deactivated schedule
GitLab deactivates a pipeline schedule when its owner is blocked, removed from the project, or their token expires — and a schedule can be toggled inactive with no alert. Your nightly job just stops firing.
Email to the wrong person
GitLab's pipeline emails go to the user who triggered the run — often a teammate who left, or an inbox filter you stopped reading. Nobody watching = nobody paged.
Stuck in pending
A pipeline waiting for an available runner — none online, tags
unmatched, quota hit — sits in pending
and never fails. It isn't a failure yet, so no failure email
ever comes.
Adding a curl ping job to .gitlab-ci.yml (the
classic heartbeat approach) fixes none of the hard cases: the job never
executes when the pipeline is stuck in pending or when the
schedule was silently deactivated. The fix is to listen to GitLab's own
pipeline signal instead — and to expect it on a schedule, so
absence is an alert too.
Setup: one webhook, about two minutes
No .gitlab-ci.yml changes, no runner config — a plain
project webhook, secret-token-verified on every delivery. Works on
GitLab.com and self-managed.
Create a CI check in LastPing
In the console, create a check, choose Monitor a CI/CD pipeline, and select GitLab. Give it the same schedule as your pipeline (e.g. daily with a grace window) so a pipeline that never starts is caught too. Copy the webhook URL and the one-time secret token shown on screen.
Register the webhook in your project
On GitLab: Settings → Webhooks → Add new webhook.
- URL — the webhook URL from step 1
- Secret token — the one-time secret from step 1 (GitLab sends it in the
X-Gitlab-Tokenheader) - Trigger — tick Pipeline events (leave Push events unticked)
- Keep SSL verification enabled and click Add webhook
Done — every pipeline now reports in
LastPing verifies each delivery's secret token, then classifies
the pipeline: running/pending as started,
success as success, failed as a failure
(canceled and skipped are ignored). Branch
and pipeline-name filters let you count only the runs you care
about. Alerts go to email by default — your verified address is
attached automatically — and to Telegram, Slack, Discord, or a
signed webhook if you add them.
Optional: attach the failure reason to the incident
A small on_failure job in the .post
stage POSTs a message (up to 64 KB, plain text) to the check's
detail endpoint. It's stored on the open incident and shown in the
console — so the alert doesn't just say "it broke," it shows why.
The body is never logged server-side.
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 pipelines — incident opens with a deep link to the exact pipeline, plus the failure detail if you added the optional job.
- Stuck pipelines — a run that reports
running/pendingbut never finishes; the completion signal doesn't arrive in the window, and that silence opens an incident. - Pipelines that never start — including schedules GitLab silently deactivated. No pipeline signal in the expected window → incident.
- Recovery — the next successful pipeline closes the incident and sends a recovery notice automatically. No manual reset.
- Flap protection — a pipeline that fails and immediately recovers within the damping window doesn't page you.
Prefer the classic style? You can still end any job with
curl -fsS https://ping.lastping.dev/<id> as a plain
heartbeat — it works, and it's the right tool for scripts inside
a pipeline. Just know its limits: it can't see pipelines stuck in
pending or deactivated schedules. The webhook can.
GitHub Actions and
Jenkins are supported the same way — or
see the copy-paste guides for cron, Kubernetes,
systemd, and more.
Questions people ask
Front-loaded answers — the most important fact first.
-
How do I get alerted when a GitLab CI pipeline fails?
Add one webhook in your project (Settings → Webhooks) with the Pipeline events trigger and point it at LastPing — zero changes to your
.gitlab-ci.yml. Every pipeline reports in; a failed, stuck, or never-started pipeline opens an incident and alerts you by email, Telegram, Slack, Discord, or webhook, with a deep link. Free, no monitor cap. -
Why did my scheduled GitLab pipeline stop running?
GitLab deactivates a pipeline schedule when its owner loses access to the project (blocked, removed, or an expired token), and a schedule can be toggled inactive without an alert. GitLab's own notifications only email the user who triggered a pipeline, so a schedule that quietly stops firing notifies nobody. A dead-man's-switch monitor expects a pipeline signal on your schedule and opens an incident when it doesn't arrive.
-
Do I need to change my .gitlab-ci.yml?
No. Monitoring uses GitLab's Pipeline events webhook, registered once per project in Settings → Webhooks. Optionally, a small
when: on_failurejob attaches a failure message to the incident — but the monitoring itself needs zero.gitlab-ci.ymlchanges. -
Does this work for self-managed GitLab and private projects?
Yes. It works with GitLab.com and self-managed GitLab, public and private projects alike. GitLab sends the secret token you set on the webhook in the
X-Gitlab-Tokenheader, which LastPing verifies on every delivery before processing — it never needs read access to your code. -
Is this free?
Yes. CI/CD monitoring is a first-class free feature — no monitor cap. GitHub Actions and Jenkins are supported the same way. See how LastPing compares to Healthchecks.io and Cronitor.
Your next silent pipeline failure is already scheduled.
One webhook now beats a post-mortem later. First alert wired up in about two minutes — and LastPing monitors itself the same way.