Monitor Jenkins — and get told why a build failed
Point the Jenkins Notification plugin at LastPing — no
Jenkinsfile
changes. Every build reports in; one that fails, gets stuck in the queue,
or never starts — even when the controller itself is down — opens an
incident, alerts you where you work, and links to the build. Free for
individuals, no monitor cap.
Jenkins can't tell you it's down.
If you run a nightly build, a backup, or a cert renewal on a Jenkins timer, three failure modes are waiting — and the notification comes from the same process that just failed.
The dead controller
When the Jenkins controller crashes, hangs, or the host reboots, the mailer never fires — the thing that sends alerts is the thing that died. Your scheduled builds just stop, silently.
Stuck in the queue
A build waiting for an executor — every agent offline, a label with no node, quota exhausted — sits in the queue and never starts. It's not a failure, so no failure email is sent.
Mailer config rot
SMTP credentials expire, a relay changes, email-ext gets misconfigured — and build emails vanish with no error you'll notice until the incident you missed.
Ending a build step with a curl ping (the classic heartbeat)
fixes none of the hard cases: the step never runs when the build is stuck
in the queue or the controller is down. The fix is an external watchdog
that expects a build signal on your schedule — so
absence is an alert too, and it doesn't depend on Jenkins being
alive to send it.
Setup: one plugin, about three minutes
No Jenkinsfile changes — the Notification plugin sends build events over HTTP, authenticated with a custom header LastPing verifies on every delivery.
Create a CI check in LastPing
In the console, create a check, choose Monitor a CI/CD pipeline, and select Jenkins. Give it the same schedule as your job (e.g. daily with a grace window) so a build that never starts is caught too. Copy the webhook URL and the one-time secret shown on screen.
Install the Notification plugin
Manage Jenkins → Plugins → Available → install Notification (by tikal), then restart if prompted. It adds a Job Notifications section to each job's configuration.
Add the endpoint on your job
On the job: Configure → Job Notifications → Add Endpoint.
- Format —
JSON - Protocol —
HTTP - Event —
All Events(covers started + completed) - URL — the webhook URL from step 1
- HTTP header — add
X-LastPing-Token= the one-time secret from step 1
Done — every build now reports in
LastPing verifies the X-LastPing-Token header, then
classifies each event: STARTED as started,
COMPLETED/FINALIZED with
SUCCESS as success, with FAILURE/UNSTABLE
as a failure (ABORTED is ignored). Alerts go to email
by default — and to Telegram, Slack, Discord, or a signed webhook if
you add them. Optionally, attach the failure reason with a
declarative-pipeline post block:
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 builds — incident opens with a link to the exact build, plus the failure detail if you added the optional post block.
- Hung builds — a build that reports
STARTEDbut never completes; the completion signal doesn't arrive in the window, and that silence opens an incident. - Builds that never start — a dead controller, all agents offline, or a job stuck in the queue. No build signal in the expected window → incident.
- Recovery — the next successful build closes the incident and sends a recovery notice automatically. No manual reset.
- Flap protection — a build that fails and immediately recovers within the damping window doesn't page you.
Prefer the classic style? You can still end any build step with
curl -fsS https://ping.lastping.dev/<id> as a plain
heartbeat — it works, and it's the right tool for scripts inside
a build. Just know its limits: it can't see a dead controller or a
queue-stuck build. The Notification webhook can.
GitHub Actions and
GitLab CI 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 Jenkins build fails?
Install the Notification plugin, add a JSON/HTTP endpoint on the job pointing at LastPing, and send an
X-LastPing-Tokenheader with your secret — no Jenkinsfile changes. Every build reports in; a failed, queue-stuck, or never-started build opens an incident and alerts you by email, Telegram, Slack, Discord, or webhook, with a link to the build. Free, no monitor cap. -
How do I know if my Jenkins controller or agent is down?
Jenkins can't email you that it's down — the same process that sends notifications is the one that failed. Because LastPing expects a build signal on your schedule and alerts on absence, a controller that crashes, an offline agent, or a job stuck in the queue all open an incident when the expected signal doesn't arrive. The watchdog lives outside Jenkins.
-
Do I need to change my Jenkinsfile?
No. Monitoring uses the Notification plugin, configured once per job under Job Notifications — it sends
STARTED,COMPLETED, andFINALIZEDevents with no pipeline changes. Optionally, apost { failure { … } }block attaches the failure reason to the incident. -
How does LastPing authenticate Jenkins webhooks?
The Notification plugin sends a custom HTTP header,
X-LastPing-Token, carrying the one-time secret from your LastPing check. LastPing compares it constant-time on every delivery and rejects anything without a valid token, so only your Jenkins can report in. -
Is this free?
Yes. CI/CD monitoring is a first-class free feature — no monitor cap. GitHub Actions and GitLab CI are supported the same way. See how LastPing compares to Healthchecks.io and Cronitor.
Your next silent build failure is already scheduled.
One plugin now beats a post-mortem later. First alert wired up in about three minutes — and LastPing monitors itself the same way.