AI AGENTS · HEARTBEAT · CI/CD · UPTIME

For everything that fails by going quiet.

LastPing catches the failures that never send an error: the AI agent that stopped mid-task and told nobody, the cron that ran but didn't finish, the CI pipeline that hung at the last step, the endpoint that started returning 200 but serving garbage. Your job pings in; if it goes silent, LastPing opens an incident and pages you — before your users notice. Free for individuals, fully hosted, first alert in under two minutes.

Get started Follow the project
For AI agents

An agent can set up its own monitoring

A long-running agent is the hardest thing in this list to monitor. It does not crash — it stalls, loops, or quietly waits for a human who never comes. Point one at mcp.lastping.dev and it creates its own monitor, instruments itself, and reports as it works. No human has to write the monitoring for it first.

MCP · 36 tools

The whole product, available to the agent itself

A hosted MCP server with 36 tools, plus a standalone binary at full tool parity. Anything you can do in the console — create a monitor, add a destination, route an event, open a status page — an agent can do over MCP.

How it works

  • The agent calls register_agent and create_monitor — no console visit required
  • It reports start, success, fail and blocked, plus progress steps within a run
  • It declares what a normal run looks like up front — expected cadence, run budget, step budget
  • The agent registry and fleet view show every agent's monitors, live status and last-seen in one place

What it catches

  • Blocked: the agent stopped mid-task waiting on a person — an approval, credentials, a decision — and nobody knew
  • Silence between runs: a silence floor (expect_every_s) catches an agent that quietly stops reporting altogether, which no cadence rule can see
  • Looping or running away: a metric guard puts a ceiling on a number the agent reports about itself, before it burns the budget
  • Finished, achieved nothing: an output assertion opens an incident on a successful run whose result fails the condition
mcp.lastping.dev
36 tools · hosted · standalone binary at parity
Monitor types

What LastPing watches — and how

Each monitor type uses the same durable detection engine and alert pipeline. Pick the one that matches your signal.

01 · Heartbeat / cron

Dead-man's-switch for scheduled jobs

Your cron job, backup script, or data pipeline calls a LastPing URL when it finishes. LastPing expects that call on a schedule. If the window passes with no ping, it's not a network error you'll see in logs — it's silence. LastPing detects silence and opens an incident.

How it works

  • Add one curl to the end of your job — no library, any language
  • Set the expected period (e.g. every 1 h) and a grace window
  • Optionally a run budget (max_runtime_s) and a progress budget (step_timeout_s) for long multi-stage jobs
  • Transitions: up → late → down on durable database deadlines, not in-memory timers
  • A restart or redeploy never misses a due check
  • On recovery: incident closes, recovery alert fires automatically
# end of your cron job
curl -fsS https://ping.lastping.dev/<id>

What it catches

  • Job ran but crashed before completing
  • Cron expression drifted or was removed
  • Scheduler stopped or container was evicted
  • Job took so long it overlapped the next window
  • Job started, stopped making progress mid-way, and never failed — optional: report a /step per stage and set step_timeout_s
  • Silent Python except: pass swallowed the error
  • Job exited zero having done nothing — set an output assertion and a successful run whose ping body fails the condition opens an incident anyway
  • Job ran away or looped — set a metric guard, a ceiling on a number the job reports about itself, and blow through it and you hear about it
02 · CI/CD signals

Pipeline visibility via signed webhooks

LastPing receives a signed webhook when a GitHub Actions workflow, GitLab CI pipeline, or Jenkins job starts and when it finishes. You get an alert on failure, on silence (job started but never reported back), and on recovery — with a deep-link to the exact run.

How it works

  • One webhook URL per monitor — register it in your CI provider in under a minute
  • Payloads are HMAC-signed; LastPing verifies before processing
  • Detects: explicit failure, job started but never completed (silence), and consecutive-failure streaks
  • Alert body includes a deep-link to the CI run — one click to the log
  • Zero YAML config on the LastPing side

Supported providers

  • GitHub Actions
  • GitLab CI / GitLab.com
  • Jenkins (webhook plugin)
  • Any CI system that can POST a signed JSON payload

What it catches

  • Failed deploy that left prod in a broken state
  • Pipeline that started, hung, and never reported back
  • Silently cancelled run after an infra hiccup
03 · HTTP / uptime

LastPing probes your URL on a schedule

Point LastPing at any public URL. Our prober hits it on your chosen interval, checks the HTTP status code, measures response latency, and optionally scans the body for a keyword. Go down, go slow, or start serving wrong content — you hear about it immediately.

How it works

  • Give LastPing a URL — no agent to install on your server
  • Choose probe interval (seconds to minutes)
  • Check: status code, latency threshold, and/or keyword presence in body
  • SSRF-guarded: probes never reach private IP ranges or cloud-metadata endpoints
  • Same detection engine as heartbeat: up → late → down

What it catches

  • Service completely down (non-2xx or timeout)
  • Latency spike above threshold
  • Response body missing expected keyword (content drift)
  • SSL cert expired or TLS handshake failure
  • DNS failure or routing black hole
Alert pipeline

Route the right signal to the right channel

Nine delivery channels. A routing matrix to decide what goes where. Custom message templates. Flap damping so you only get paged when it matters.

Delivery channels

Email
Confirmed opt-in. Default channel — fires on the very first check, no config needed.
Slack
Incoming webhook. Rich message with monitor name, status, and deep-link to the incident.
Discord
Discord webhook. Same rich payload as Slack, coloured by incident severity.
Telegram
Bot message to any chat or group. Instant push with no polling overhead.
Webhook (outbound)
HMAC-signed JSON POST to your URL. SSRF-guarded. Pipe into PagerDuty, Opsgenie, or any custom handler.
Microsoft Teams
Incoming webhook to a Teams channel. Same rich payload as Slack.
Google Chat
Incoming webhook to a Google Chat space. Same rich payload as Slack.
Pushover
Push straight to your phone or watch, with per-incident priority.
ntfy
Topic-based push. Point it at any ntfy topic URL, with an optional auth token.

Routing matrix

Channel
Down
Fail
Blocked
Recover
email
✓
✓
✓
—
slack
✓
✓
✓
✓
telegram
✓
—
✓
—
pushover
✓
—
—
—
webhook
✓
✓
✓
✓

Illustrative — every one of the nine destinations gets its own row. Toggle each cell per-monitor: one check can page Telegram on down, email on recovery, and webhook on everything. Blocked fires when an agent stops mid-task waiting on a person — approval, credentials, a decision.

Four more event types are routable the same way for progress reporting rather than paging: started, success, every-run and note. They are never routed by default — one or more fire per run, so they belong on a destination you opt in.

Custom message templates

Write your own alert body using template variables: {check_name}, {status}, {run_url}. Inline variables with a live preview; per event type, so your down alert can read differently from your recovery notice.

Flap damping + rate caps

If a check goes down and recovers within a short window, the alert is held and cancelled on recovery — a single blip does not page you. Per-channel rate caps suppress duplicate notifications for the same incident within a minimum interval.

Surfaces

Four ways in. None of them is second-class.

Every capability on this page exists in the web console, the REST API, the MCP server and the Terraform provider. A feature is not shipped here until all four agree.

API · Terraform · Metrics

Drive it from code, not just the console

The console is one client of the same REST API you get. Monitors, destinations, routes and status pages all live in version control if you want them there.

Code, API and Terraform

  • REST API with a published OpenAPI document and interactive docs
  • Terraform provider for monitoring-as-code — monitors, destinations, routes and status pages in version control
  • Partial PATCH with merge-patch semantics: send only the fields you are changing
  • Per-project Prometheus /metrics endpoint to scrape into Grafana or Alertmanager
terraform-provider-lastping
registry.terraform.io/providers/lastping-dev/lastping

What parity actually means

  • A capability ships on all four surfaces together, or it does not ship
  • The console calls the same public REST API you do — there is no private endpoint it uses and you cannot
  • Anything you can click, an agent can call over MCP, and Terraform can declare
  • Deviations get stated on the page, not left for you to discover
web console · REST + OpenAPI
MCP · Terraform
one capability, four surfaces
Status pages

Public status pages — no extra service needed

Share a live status page with your users. Backed by the same monitors that already power your alerts — no duplicate configuration.

Shareable public URL

Each project gets a public status URL. Share it with customers, put it in your docs, link it from your app. No separate hosting. No additional cost.

Embeddable badge

Drop a live-updating status badge into any README, docs page, or landing page. One line of HTML — the badge reflects real-time status from your monitors.

● all systems operational

Choose which monitors to show

Not every internal monitor belongs on a public page. Pick which checks are visible on the status page per-project. Internal cron jobs can stay private; the API uptime check can be public.

Live — no polling required

Status pages reflect real monitor state in real time. When an incident opens, the page updates automatically. Your users see the same state you do.

The console

Terminal-native Slate UI — everything in one place

Overview, Monitors, Incidents feed with MTTR, and Analytics over CI run data. Dense, readable, dark — built for engineers who live in terminals.

▦ overview · prod
▦ incidents · last 7d
▦ monitors · all
▦ analytics · ci runs · 30d

Illustrative. Your console shows your real checks, incidents, and run data.

FREE FOR INDIVIDUALS · FULLY HOSTED

First alert in under two minutes.

Add one curl to your cron job. LastPing handles the rest — detection, incidents, alerts — free for individuals, no setup required. Follow the project on GitHub for updates and to file issues.

Get started GitHub