Docs
Pick your platform for a step-by-step guide, or read the reference below. Every check's Setup tab also has copy-paste snippets with its own URL filled in.
Guides
- GitHub ActionsGitHub Actions scheduled workflow not runningThe 60-day rule, delayed runs, and three pings that catch both.
- Cloudflare WorkersMonitor Cloudflare Workers Cron TriggersPing from scheduled(), and report failures from the catch.
- crontabFind out when a crontab job fails silentlyOne curl after the command, plus cron's PATH and MAILTO.
- Vercel CronMonitor Vercel Cron JobsPing from the route the cron calls, and report failures.
- pg_cronMonitor pg_cron jobs in PostgresPing with pg_net after the job commits, and on failure.
Coming next: Kubernetes CronJobs
Ping URLs
Each check has its own URL. Your job calls it; nothing else is needed. Any HTTP method works, usually GET or POST.
| URL | Records | Alerts |
|---|---|---|
/p/<check-id> | A successful run. | If the check was late or failed, we tell you it recovered. |
/p/<check-id>/start | That a run began. | None. |
/p/<check-id>/fail | A failed run. | Within a minute, without waiting for the grace period. |
Run this after your job finishes:
curl -fsS -m 10 --retry 5 -o /dev/null https://lateping.com/p/<check-id>We don't store request bodies or IP addresses. Each ping keeps its time, its kind and a country code.
Responses
200 OK: the ping was recorded.404 Not found: no check has that ID, or the URL is malformed. Withcurl -f, a wrong ID fails the command instead of passing silently.500 Error: our side failed.--retry 5tries again; a ping that never lands shows up as a late check, not a missing alert.
Timing a run
Call /start before the job and the plain URL after it. Lateping records both, so you can see when each run began and finished. On Pro and above, the check's Analytics tab shows run times, averages and charts, and exports them as CSV.
curl -fsS -m 10 --retry 5 -o /dev/null https://lateping.com/p/<check-id>/start
curl -fsS -m 10 --retry 5 -o /dev/null https://lateping.com/p/<check-id>Put your job's own commands between the two lines. To report a failure straight away, call/fail when the job exits non-zero; the guides show how on each platform.
Schedules and grace
- Every N minutes: the next ping is due N minutes after the last one.
- Cron expression with a timezone: the next ping is due at the next scheduled time, in that timezone. GitHub Actions and Cloudflare Cron Triggers run in UTC.
- Grace: how long we wait after a ping is due before alerting. Allow for the job's run time and any queue delay. 30 minutes suits most nightly jobs.
A new check starts with its first ping. Until then, it never alerts.
Alerts
- Late: no ping arrived before the grace period ended.
- Failed: your job called
/fail. - Recovered: a successful ping arrived after a late or failed alert.
Alerts go to your account email. From the panel's Destinations tab you can add more email addresses on any plan, and Slack, Discord or a signed webhook on Pro and above.
Pausing a check
Pause a check from its Settings tab, for example during maintenance. A paused check doesn't alert when pings stop. The next successful ping starts it again, and a /fail ping still alerts.