LastPing monitors LastPing.
A monitoring product that fails silently would be the worst irony in software. So LastPing watches itself: six ordinary HTTP checks — the same kind any customer creates, through the same public API and dashboard — watch LastPing's own ping ingest, app, MCP server, login, docs, and marketing site, around the clock. The results, uptime history and all, 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 own endpoints — ping ingest, API, MCP server, login, docs, marketing site — are monitored by LastPing itself, alerts page the builder on Discord and email like any other user's would, and the current state, incidents included, is on a public status page — served by the same status-page feature you can use.
What LastPing watches about itself
The same account, the same dashboard, the same public API — holding these six checks:
Six HTTP probes watch the ping ingest endpoint, the app health endpoint, the MCP server, the login page, the docs, and the marketing site.
Illustrative rendering — the live state is on the public status page.
What this does — and doesn't — prove
No dramatics. Six checks, watched the same way a customer would watch them.
Ordinary HTTP checks, same account
Six monitors — ping ingest, API health, the MCP server, login, docs, marketing — created the same way any customer's are: through LastPing's dashboard and public REST API. No internal-only tooling, no elevated access.
Incidents shown, not hidden
On 22 July, four of these components missed their check window and recovered within minutes. That incident is still on the status page. A status page that has never shown an incident is a status page nobody believes.
The HTTP path, end to end
Probing, alerting, and the public status page itself run continuously on real infrastructure — this page's own uptime numbers and incident history are the evidence, not a claim.
Heartbeat detection
These six checks are HTTP probes. They don't exercise the heartbeat / absence-detection path — the mechanism that catches a job that silently stops running, which is LastPing's core pitch.
Nothing on this page is rendered specially for marketing — the console above mirrors what the live status page shows, incident history included.
Questions people ask
Front-loaded answers — the most important fact first.
-
Does LastPing monitor itself?
Yes. Six ordinary HTTP monitors — the same kind any LastPing customer creates — watch LastPing's own ping ingest endpoint, the app's health endpoint, the MCP server, the login page, the docs, and the marketing site. Alerts route to Discord and email, and the results, including 90 days of uptime history, are on a public status page.
-
What does this prove — and what doesn't it?
It proves the HTTP probing path, alerting, and the public status page work continuously on real infrastructure — including catching a four-component incident on 22 July that's still shown on the page rather than removed. It doesn't exercise heartbeat or absence detection, the mechanism LastPing uses to catch a job that stops running silently, because these six checks are ordinary HTTP probes, not heartbeats.
-
Does this use special internal access?
No. These monitors, alert routes, and the status page are ordinary objects in a LastPing account, created and read through the same public REST API and dashboard every customer uses via the API — no internal-only tooling, no privileged access.
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.