GUIDE · HTTP / UPTIME · FREE

Uptime monitoring that tells you why it's down

Heartbeat monitors wait for your jobs to call in. HTTP monitors work the other direction: LastPing polls your URL — as often as every 30 seconds — checks the status code and an optional body keyword, records latency, and puts the exact failure reason on the incident: status 500, expected 200, not just "down". Free, no monitor cap.

Start monitoring — free All monitoring guides

How a probe decides up or down

Every probe runs the same three checks, in order — and the first one that fails becomes the reason on your incident.

Check 01 · reachability

Can the URL be reached at all?

Timeout, DNS failure, TLS error, refused connection — the probe is down with reason unreachable: timeout (or the matching class). The request is capped by your timeout setting (1–30 s, default 10 s).

Check 02 · status

Is the status code right?

Expect a specific code (200 by default) or any 2xx. A mismatch is down with the exact evidence: status 500, expected 200.

Check 03 · keyword

Does the body say what it should?

Optionally require a string — the probe scans the first 64 KB of the response and goes down with body match failed if it's absent. Catches the 200-OK-but-broken page.

All three pass → the probe is up, and its latency (in milliseconds) is recorded either way — so you see response-time trends, not just up/down.

Setup: about a minute, no code at all

HTTP monitors are configured entirely in the console — there's nothing to install or embed.

Create an HTTP monitor

In the console, create a monitor and choose HTTP / uptime. Enter the URL to probe — ideally a real health endpoint:

https://example.com/health

Set the expectations

  • Method — GET, HEAD, or POST
  • Interval — every 30 seconds up to every 24 hours (default: 60 s)
  • Timeout — 1–30 seconds (default: 10 s)
  • Expected status — a specific code like 200, or any 2xx
  • Body keyword — optional string the response must contain
  • Follow redirects — follow up to 10 hops, or evaluate the 3xx response as-is

Route the alerts

Your verified email is attached automatically — the first alert needs zero routing setup. Add Telegram, Slack, Discord, or a signed webhook if you want alerts there too. When the probe goes down, the incident carries the exact reason and the next successful probe closes it with a recovery notice.

Optional: status page and badge

Add the monitor to a public status page with 90-day uptime bars, and embed the per-monitor SVG badge in your README. Both free.

Good to know

The defaults are tuned so a single bad probe never wakes you up for nothing.

  • No single-probe false alarms — the grace window is always at least 2× the probe interval, so one slow or dropped probe can't fire an alert on its own.
  • Identifiable probes — every probe sends User-Agent: LastPing-Prober/1. Allowlist it if you filter bots or rate-limit.
  • Public URLs only — probes refuse private, loopback, and cloud-metadata addresses by design (SSRF protection). For internal services, use a heartbeat monitor: the service pings out, no inbound access needed.
  • Probe a health endpoint, not the homepage — a /health that checks its own dependencies and returns ok makes the keyword check meaningful.
  • Flap protection — a probe that dips and recovers within the damping window doesn't page you.

HTTP monitors cover "is it reachable"; heartbeat monitors cover "did it run". Most stacks want both — see the cron, Kubernetes, and backup guides, or all guides.

Questions people ask

Front-loaded answers — the most important fact first.

  • How often can LastPing check my site?

    As often as every 30 seconds, up to as rarely as every 24 hours; the default is every 60 seconds. All intervals are free — there's no paid tier.

  • What counts as down?

    Three things, each with its own reason on the incident: the URL was unreachable (timeout, DNS, TLS, connection), the status code didn't match your expectation, or the required keyword was missing from the response body. Latency is recorded on every probe either way.

  • Can it check page content, not just the status code?

    Yes — set a body keyword and the probe fails with body match failed if the string is absent from the first 64 KB of the response. That catches the 200-OK-but-broken page a status check waves through.

  • Can I monitor internal or private URLs?

    No — probes refuse private, loopback, and cloud-metadata addresses by design (SSRF protection), so HTTP monitors are for publicly reachable URLs. For internal services and jobs, flip the direction: a heartbeat monitor has the service ping LastPing outbound, which needs no inbound access at all.

  • Is this free?

    Yes — including the 30-second interval, status pages, and badges. No monitor cap, no paid tier. See how LastPing compares to Healthchecks.io and Cronitor.

FREE · FULLY HOSTED · NO PAID TIER

"Is it down?" deserves a better answer than "yes".

Status code, latency, and the exact failure reason — wired to your inbox in about a minute. LastPing monitors itself the same way.

Start monitoring — free All monitoring guides