A stopped agent looks exactly like a thinking one.
LastPing watches the agent run itself: started, progress, blocked, failed. Not just the jobs an agent manages. The same engine covers cron jobs, backups and CI pipelines, and opens an incident the moment an expected signal doesn't arrive.
Three monitor types
Cron & backups
Your job pings when it finishes. Miss the window and LastPing opens an incident and alerts you. The classic dead-man's switch. It catches silent failures a broken job can never report itself.
Pipelines
One signed webhook from GitHub Actions, GitLab CI, or Jenkins. zero YAML. A run that starts, hangs, silently fails, or never starts at all opens an incident with the failure detail and a deep link to the run. How CI monitoring works →
Endpoints
Point LastPing at any URL. We probe it on schedule for status code, latency, and keyword presence. Go down or slow down and you hear about it immediately.
Absence detection
How it works
Three signals in, one durable detection engine, alerts wherever you work.
Signal in — ping, webhook, or probe
Add curl -fsS https://ping.lastping.dev/<id>
to the end of your cron job, configure a webhook in your CI
provider, or give LastPing a URL to probe. No agent. No library.
Works from any language or one shell line, with
copy-paste guides for cron, Kubernetes,
systemd, Python, and Node.
Detect on durable deadlines
Each check has an expected schedule and a grace period. Detection runs on durable deadlines in the database, not in-memory timers, so a crash, restart, or deploy never misses a due check. When a check goes silent, it transitions up → late → down.
For long jobs, a run can also report progress: call
/step as each stage finishes and set
step_timeout_s on the monitor. If nothing reports
for that long, a stalled incident opens naming
the step the run wedged in, minutes in, instead of waiting out
a four-hour run budget. It is opt-in: leave
step_timeout_s unset and nothing changes.
Alert — one incident, not a storm
LastPing opens a single incident and fires alerts the moment a check goes down. Flap damping cancels the alert if the job recovers within seconds. When the job checks back in, the incident closes and you get a recovery notice. No manual reset required.
AI agents
AI agents check in too
One run is one task. An agent reports start when it
picks one up, and success or fail when it
reports back.
start— the agent picked up a task.blocked— it stopped mid-task to ask you something, and is waiting on an answer.success/fail— it reported back.
Every blocked report is a run sitting on a person's desk
Before this, nothing told you. More on tracking a fleet of agents:
how LastPing monitors AI agents →
The whole integration
One request per moment that matters.
That is the entire integration. No SDK, no agent process, no library to keep up to date. Anything that can make an HTTP request can report, in any language. Miss the window and LastPing opens the incident for you.
Free for individuals, and fully hosted.
LastPing is free for individuals. No setup, no infra. Sign up and start monitoring in minutes. Everything runs on our infrastructure. Follow the project on GitHub for updates and to file issues.
FAQ
Questions engineers ask
Front-loaded answers: the most important fact first.
-
What is LastPing?
LastPing is a dead-man's-switch monitor for scheduled jobs, CI/CD pipelines, and HTTP endpoints. Instead of actively pinging your services, it waits for them to check in. If a job goes silent — a cron that never ran, a CI pipeline that hung, an endpoint that stopped responding — LastPing opens an incident and alerts you before your users notice.
-
Is LastPing free?
Yes. LastPing is free for individuals at app.lastping.dev — no monitor cap, no feature gate. Everything runs on our infrastructure; no setup required. Follow the project at github.com/tp322d/lastping-app.
-
How do I get alerted when a job goes down?
Alerts fire automatically on the very first check you create. LastPing emails the account owner by default, no routing to configure. You can add Telegram, Slack, Discord, or signed outbound webhooks and choose which events reach which channel per check.
-
Does LastPing support CI/CD pipelines and HTTP uptime?
Yes. LastPing supports three monitor types: heartbeat (cron/scheduled jobs that ping when they finish), CI/CD signals (signed webhooks from GitHub Actions, GitLab CI, Jenkins — zero YAML, deep-link to the run on alert), and HTTP/uptime probing (LastPing polls your URL on schedule for status code, latency, and keyword presence).
-
Can LastPing monitor GitHub Actions workflows?
Yes. Point one signed webhook at LastPing from your repository settings, ticking both the
workflow_runandworkflow_jobevents — zero changes to your workflow YAML. LastPing alerts when a run fails, hangs, or never starts (including scheduled workflows GitHub silently disables after 60 days of repo inactivity), deep-links to the run, and can attach the failure log excerpt to the incident. Setup guide → -
How is LastPing different from Healthchecks.io?
Healthchecks.io is an excellent heartbeat monitor for cron jobs. LastPing covers cron jobs the same way — your job curls a ping URL — and additionally treats CI/CD pipelines as first-class monitors: one signed webhook from GitHub Actions, GitLab CI, or Jenkins, no curl step in every workflow, catching runs that fail, hang, or never start, with failure detail on the incident. LastPing is free for individuals with no monitor cap. Full comparison →
-
Where can I follow LastPing development?
Follow the project on GitHub at github.com/tp322d/lastping-app. That is where development is tracked, issues are filed, and upcoming work is discussed. See the project page for more.
-
What alert channels does LastPing support?
Email, Telegram, Slack, Discord, and signed outbound webhooks. Email channels use confirmed opt-in, and delivery is SSRF-guarded so alerts can never reach internal or cloud-metadata addresses.
-
How does LastPing prevent false alarms from flapping checks?
LastPing damps flapping: if a check goes down and recovers within a short window, the alert is held and cancelled on recovery so a single blip does not page you. Per-channel rate caps back this up, and duplicate notifications for the same incident are suppressed within a minimum interval.