GUIDES · COPY-PASTE · FREE

Copy, paste, monitored.

Every guide below ends in a working snippet — a crontab line, a manifest, a unit file, a try/except — against the real ping API. Pick your environment, paste the block, and the next silent failure has a pager.

# the universal integration — everything else is variations: your-job && curl -fsS -m 10 --retry 3 -o /dev/null https://ping.lastping.dev/<your-monitor-id>

The ping API, in five lines

Every monitor has one URL; suffixes change the meaning. GET, HEAD, or POST — a POSTed body (up to 10 KB) is stored with the ping, and ?rid= pairs a start with its finish to record run duration.

https://ping.lastping.dev/<id> → success https://ping.lastping.dev/<id>/start → run started (arms overrun detection) https://ping.lastping.dev/<id>/fail → explicit failure (alerts immediately) https://ping.lastping.dev/<id>/<code> → exit code: 0 = success, non-zero = fail https://ping.lastping.dev/<id>/log → attach a note; no state change

Pick your environment

Heartbeats for things that run, probes for things that serve, and the alerting reference that shapes what lands in your channel.

Heartbeat · Linux

Cron jobs

The flagship one-liner: append a curl to the crontab line; failures, hangs, and vanished schedules all alert.

job && curl -fsS -m 10 --retry 3 …/<id>
Heartbeat · Kubernetes

Kubernetes CronJobs

A copy-paste manifest — success and failure pings from the job command, no operator, nothing installed in the cluster.

if /app/job.sh; then curl "$LASTPING_URL"; else …
Heartbeat · systemd

systemd timers

ExecStartPost pings success, OnFailure pings failure, absence covers the timer that stopped firing. Three unit files.

ExecStartPost=/usr/bin/curl -fsS …/<id>
Heartbeat · pattern

Backups

Start → work → success/fail, with the error log POSTed on failure and run duration recorded. The anti-horror-story.

curl …/start · pg_dump … · curl …/fail
Heartbeat · in code

Python

A try/except with requests or plain stdlib — ping on success, POST the exception on failure, re-raise for the exit code.

requests.post(f"{PING}/fail", data=str(exc))
Heartbeat · in code

Node.js

Built-in fetch, zero dependencies — ESM and CommonJS variants, with the stack trace attached to the fail ping.

await fetch(`${PING}/fail`, { method: "POST" … })
CI/CD · webhook

GitHub Actions

One signed workflow_run webhook, zero YAML changes — catches failed, hung, and never-started runs with failure detail.

Settings → Webhooks → workflow_run
CI/CD · webhook

GitLab CI

One Pipeline-events webhook, zero .gitlab-ci.yml changes — catches failed, pending-stuck, and never-started pipelines with failure detail.

Settings → Webhooks → Pipeline events
CI/CD · webhook

Jenkins

One Notification-plugin endpoint, no Jenkinsfile changes — catches failed, queue-stuck, and never-started builds, even a dead controller.

Job Notifications → JSON / HTTP
Probe · uptime

HTTP & uptime

LastPing polls your URL every 30 s–24 h: status code, latency, optional body keyword — with the exact reason on the incident.

status 500, expected 200 · body match failed
Reference · alerting

Alert events & templates

down, fail, recovery, every-run — the routing matrix and per-event message templates with 16 variables.

[LastPing] {check_name} {event} ({cause})

Deciding between tools first? Read the honest comparisons with Healthchecks.io and Cronitor, see how LastPing monitors itself, or go straight to the full documentation.

FREE · FULLY HOSTED · NO PAID TIER

Somewhere in your stack, a job is failing politely.

Every snippet on these pages is wired in minutes — and LastPing monitors itself the same way.