LastPing monitors LastPing.
A monitoring product that fails silently would be the worst irony in software. So LastPing watches itself: a harness provisions a second, ordinary LastPing account that monitors LastPing's own scheduled jobs, uptime, and API — through the same public API you get — and a watchdog deliberately breaks a canary monitor, on a schedule, to prove detection works end to end. The results are public.
Why we do this
LastPing's whole pitch is that silence is the failure you can't see — a broken job can't report itself. That argument applies to us hardest of all. If our detector, ingest queue, or notifier broke quietly, every user's monitoring would be broken quietly too.
We don't have a wall of enterprise logos. What we have instead is a system that puts our own uptime where our mouth is: LastPing's crons, endpoints, and detection pipeline are monitored by LastPing itself, alerts page the builder on Discord and email like any other user's would, and the current state is on a public status page — served by the same status-page feature you can use.
What the harness watches
A second, ordinary account — no internal hooks, no special access — holding these monitors:
The harness monitors the marketing site, the app health endpoint, the login page, and the docs with HTTP probes; a 5-minute sweep, an hourly rollup, and a nightly backup job with heartbeat monitors; and the watchdog cycle with its own heartbeat monitor.
Illustrative rendering — the live state is on the public status page.
Four small programs, one honest loop
The harness is real code in the LastPing repository — not a manual checklist that rots.
Declares the desired state, converges to it
The full self-monitoring setup — checks, alert channels, routing matrix, and the public status page — is declared in code. A reconciler converges the live account to that state through the public REST API with an ordinary API key. Run it twice and it changes nothing; drift gets repaired.
Runs real scheduled jobs that ping
A 5-minute health sweep, an hourly rollup, and a nightly backup job run on real schedules and ping their heartbeat monitors on success — or signal failure explicitly. Exactly the setup we recommend to users, eaten as our own dogfood.
Breaks a canary on purpose
The interesting one. Each cycle it goes silent on a canary monitor and asserts LastPing opens an incident — proving ingest, processing, and detection end to end — then recovers the canary and asserts the incident closes. The pass/fail result pings the watchdog's own heartbeat monitor, so if the watchdog itself dies, that silence raises an alert too.
Keeps the pipeline honest under load
A bounded synthetic load generator exercises the ping-ingest path with hard caps on monitors, rate, and duration — so we see queueing or latency problems before users do.
Detection itself runs on durable database deadlines, not in-memory timers — a crash, restart, or deploy never loses a due check — and pings are buffered through a durable queue. The watchdog exists to verify those claims continuously instead of asserting them in marketing copy. This page is marketing copy; the watchdog is why you can believe it.
Questions people ask
Front-loaded answers — the most important fact first.
-
Does LastPing monitor itself?
Yes. A self-monitoring harness provisions a second, ordinary LastPing account that watches LastPing's own services: HTTP probes on the marketing site, the app's health endpoint, the login page, and the docs, plus heartbeat monitors on real scheduled jobs (a 5-minute sweep, an hourly rollup, a nightly backup). Alerts go to Discord and email, and the results are on a public status page.
-
How does LastPing prove its detection actually works?
A meta-watchdog deliberately breaks things on a schedule: it silences a canary heartbeat monitor, asserts that LastPing opens an incident (proving the ingest, processing, and detection pipeline end to end), then recovers the canary and asserts the incident closes. The cycle's result is reported to its own heartbeat monitor — so if the watchdog itself stops running, that silence raises an alert too.
-
Does the harness use special internal access?
No. The harness talks to the same public REST API every user gets, authenticated with an ordinary project API key. It declares the desired set of checks, channels, routes, and status pages and converges the account to that state — the same way any user could script their own setup with the API.
Monitored by the thing it monitors with.
Set up the same protection for your own crons, backups, and pipelines — one curl line or one signed webhook, free.