LastPing vs Healthchecks.io — free cron and CI/CD monitoring
LastPing is a free, fully-hosted alternative to Healthchecks.io with no check cap and no paid tier. It monitors cron jobs the same way — your job curls a ping URL — and additionally monitors CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins) via one signed webhook, with the failure detail on the incident.
The honest verdict, up front
If you only monitor cron jobs and you want open-source software you can self-host — or you need teams, projects, and a very broad integration list — Healthchecks.io is excellent and has a decade of track record. We use the same curl-a-ping-URL mechanism it popularised, and we're not going to pretend it doesn't work.
LastPing is the better pick when any of your scheduled work lives in CI — scheduled GitHub Actions workflows, GitLab pipelines, Jenkins jobs. Covering those with a heartbeat tool means adding a curl step to every workflow, and that step can never fire when the runner hangs or when GitHub silently disables your schedule. LastPing takes one signed webhook instead — zero YAML — and catches runs that fail, hang, or never start, with a deep link to the run and the failure detail on the incident. It's also uncapped: free with no check limit and no paid tier.
Feature by feature
Only rows we can stand behind. Where Healthchecks.io wins, the table says so.
| Capability | LastPing | Healthchecks.io |
|---|---|---|
| Free hosted tier | ✓ Free — no check cap, no paid tier | ◐ Free up to 20 checks; paid plans beyond |
| Cron / heartbeat monitoring | ✓ Curl a ping URL; cron or simple-interval schedules, grace windows, time zones | ✓ The category benchmark — mature and excellent |
| CI/CD pipelines as first-class monitors | ✓ One signed webhook per repo (GitHub Actions, GitLab CI, Jenkins) — zero YAML changes | ◐ Possible by adding a curl step to each workflow |
| Catches hung or never-started CI runs | ✓ Started-but-hung, failed, and never-ran all open incidents | ✗ A curl step can't fire if the runner hangs or the schedule was disabled |
| Failure detail on the incident | ✓ Deep link to the run + optional failure-log excerpt captured on the incident | ✗ |
| HTTP / uptime probing | ✓ Status code, latency, keyword checks | ✗ Heartbeat-only by design |
| Custom alert message templates | ✓ Per event type, with live preview | ✗ |
| Alert channels | ◐ Email, Telegram, Slack, Discord, signed webhook | ✓ Very broad — PagerDuty, Opsgenie, ntfy, Pushover, and many more |
| Open source / self-hostable | ✗ Hosted only, for now | ✓ Open source; run it yourself or use the hosted service |
| Teams & shared projects | ✗ Single-user today (top roadmap item) | ✓ |
| Public status pages | ✓ Public status pages + embeddable badges | ◐ Per-check status badges |
| Track record | ◐ New — built in public, monitors itself with itself | ✓ ~10 years in production |
The CI/CD difference, concretely
Both tools catch a silent cron job. Only one catches a silent pipeline.
With a heartbeat-only tool, monitoring a GitHub Actions workflow means editing every workflow to add a ping step. Three failure modes slip through: the runner hangs (the step never executes), GitHub silently disables scheduled workflows after 60 days of repository inactivity (nothing runs, nothing pings — from the monitor's view this looks identical to "hasn't run yet" until the check window finally lapses, and you still don't know why), and a failed run only emails whoever last touched the cron schedule.
LastPing ingests the provider's own workflow_run
signal instead: one HMAC-signed webhook per repository, registered in
the repo settings, zero YAML. Failed, hung, and never-started runs
all open incidents, the alert deep-links to the exact run, and an
optional one-line if: failure()
step can attach the failure log excerpt directly to the incident.
Full GitHub Actions guide →
Migrating takes one URL change
Both tools use the same mechanism: your job pings a unique URL when it finishes. Switching is not a rewrite.
curl -fsS https://hc-ping.com/<uuid>
# after — same line, different URL
curl -fsS https://ping.lastping.dev/<id>
Create a check in LastPing, set the same schedule and grace period, and
swap the URL. Success/failure signalling works too: append
/fail
or an exit code to the ping URL. Your first alert destination — the
account email — is attached automatically, so there is nothing else to
configure.
Questions people ask
Front-loaded answers — the most important fact first.
-
Is LastPing a free alternative to Healthchecks.io?
Yes. LastPing is a free, fully-hosted alternative to Healthchecks.io with no check cap and no paid tier. It monitors cron jobs the same way (your job curls a ping URL when it finishes) and additionally monitors CI/CD pipelines — GitHub Actions, GitLab CI, Jenkins — via one signed webhook with zero workflow YAML changes.
-
When is Healthchecks.io the better choice?
If you only monitor cron jobs and want open-source software you can self-host, need team and project sharing, or need its very broad integration list (PagerDuty, Opsgenie, ntfy, Pushover and more), Healthchecks.io is excellent and has a decade of track record. LastPing is hosted-only and single-user today.
-
Can I migrate from Healthchecks.io to LastPing?
Yes, in minutes. Both tools use the same mechanism: your job requests a unique ping URL when it finishes. Migrating is creating a check in LastPing and changing the URL your job curls — no library, agent, or code changes.
-
Can Healthchecks.io monitor GitHub Actions workflows?
Only by adding a curl step to every workflow you want covered — and that step never fires if the runner hangs or GitHub silently disables the schedule. LastPing instead ingests one signed
workflow_runwebhook per repository: zero YAML changes, and it catches runs that fail, hang, or never start, with a deep link to the run and failure detail on the incident. Setup guide →
Your crons and your pipelines. One console.
One curl for cron jobs, one signed webhook for CI. First alert in under two minutes — no card, no cap, no paid tier.