Skip to content
LastPing
COMPARISON · HONEST VERDICT

LastPing vs Healthchecks.io: free cron and CI/CD monitoring

LastPing is a fully-hosted alternative to Healthchecks.io with no check cap, free for individuals. 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.

On this page
  1. The honest verdict, up front
  2. Feature by feature
  3. The CI/CD difference, concretely
  4. Migrating takes one URL change
  5. Replacing hc-ping.com URLs
  6. Questions people ask

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 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: no check limit, free for individuals.

Feature by feature

Only rows we can stand behind. Where Healthchecks.io wins, the table says so.

Feature comparison between LastPing and Healthchecks.io
Capability LastPing Healthchecks.io
Free hosted tier ✓ Free for individuals: no check cap ◐ 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 ◐ Nine destinations: email, Slack, Discord, Telegram, signed webhook, ntfy, Pushover, Microsoft Teams, Google Chat. No SMS or phone. ✓ 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 disables scheduled workflows after 60 days of inactivity in a public repository (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.

# before — end of your cron job
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.

Replacing hc-ping.com URLs

Every hc-ping.com URL maps to a LastPing ping URL. The check ids differ, so each check gets a new monitor and a new URL.

Find every hc-ping.com URL

Search the places your jobs live: crontabs, scripts, CI workflows and container specs.

crontab -l | grep -n 'hc-ping.com'
grep -rn 'hc-ping.com' /etc/crontab /etc/cron.d . 2>/dev/null

Create one LastPing monitor per check

Copy each check's schedule (cron expression and time zone, or period) and grace time. With many checks, ask an AI assistant connected to the LastPing MCP server to propose the list and create it after you agree, or declare them with the Terraform provider.

Swap the URLs

The suffixes keep their meaning, so only the host and id change:

hc-ping.com/<uuid>          ping.lastping.dev/<id>          success
hc-ping.com/<uuid>/start    ping.lastping.dev/<id>/start    run started
hc-ping.com/<uuid>/fail     ping.lastping.dev/<id>/fail     failure, body kept
hc-ping.com/<uuid>/<code>   ping.lastping.dev/<id>/<code>   0 success, else fail
hc-ping.com/<uuid>/log      ping.lastping.dev/<id>/log      log line, no state change
?rid=<run id>               ?rid=<run id>                  pairs start and finish

Slug URLs, hc-ping.com/<ping-key>/<slug>, have no LastPing equivalent: use each monitor's own URL. A failure body is stored on the incident, up to 10,000 bytes.

Run both for a day, then remove the old URL

Ping both URLs from the same line until LastPing has seen a few runs, then delete the hc-ping.com call and the old check.

backup.sh && { curl -fsS -m 10 --retry 3 https://hc-ping.com/<uuid>; curl -fsS -m 10 --retry 3 https://ping.lastping.dev/<id>; }

Questions people ask

Front-loaded answers: the most important fact first.

  • Is LastPing a free alternative to Healthchecks.io?

    Yes. LastPing is a fully-hosted alternative to Healthchecks.io with no check cap, free for individuals. 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 disables the schedule. LastPing instead ingests one signed workflow_run webhook 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 →

  • How do I replace hc-ping.com URLs with LastPing?

    Create a LastPing monitor for each Healthchecks.io check, with the same schedule, time zone and grace, then swap the URL prefix: https://hc-ping.com/<uuid> becomes the monitor's https://ping.lastping.dev/<id>. The /start, /fail, /log and /<exit-code> suffixes and the ?rid= parameter keep their meaning. Slug URLs (hc-ping.com/<ping-key>/<slug>) have no equivalent: each LastPing monitor has its own URL.

FREE FOR INDIVIDUALS · FULLY HOSTED

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. Free for individuals.