← All guides

Free uptime monitoring with one curl — no account, webhook alerts

You have one URL — a side project, a staging API, a health endpoint — and you want a ping when it stops answering. Every monitoring product wants the same toll first: create an account, verify your email, click through a dashboard, find the webhook integration behind a settings menu. That's a lot of ceremony for "GET this URL sometimes and tell me if it dies".

Mockbird runs a public status tracker that checks 50+ developer APIs from Cloudflare's edge. The same checker can watch your URL — and the entire setup is one curl, no account:

1. The one curl

curl -X POST https://mockbird.mockbird.workers.dev/api/status/monitor \
  -H 'content-type: application/json' \
  -d '{"url":"https://api.example.com/health","notify":"https://hooks.slack.com/services/T000/B000/XXXX"}'

url is the target to monitor; notify is where alerts go — a Slack incoming webhook, a Discord webhook, or any HTTPS endpoint you control. The response comes back immediately:

{
  "id": "mon-d7c62042fa",
  "secret": "5da413d8d0454146c254819f5fefdbda",
  "url": "https://example.com",
  "current": { "ok": true, "http_status": 200, "ms": 10, "error": null },
  "checked_every_minutes": 30,
  "confirmation": { "ok": true, "status": 200 },
  "note": "confirmation delivered — you're monitoring",
  "manage": {
    "info": "GET https://mockbird.mockbird.workers.dev/api/status/monitor/mon-d7c62042fa?secret=…",
    "stop": "curl -X DELETE \"https://mockbird.mockbird.workers.dev/api/status/monitor/mon-d7c62042fa?secret=…\""
  }
}

Two useful things happen in that single round trip: current is a live check performed right now, so the endpoint doubles as a one-curl "is my site up from the outside?" probe — and a watch.test confirmation POST is delivered to your webhook immediately, so you know the alert channel works before you ever need it.

2. What you get

• Your URL is GET-checked every 30 minutes from Cloudflare's network (8s timeout, redirects followed, any 2xx/3xx counts as up).
• One webhook when it goes down, one when it recovers. Not a message every failed check — a message per transition.
• Debounced: two consecutive checks must agree before a transition fires, so a single blip never pages you.
• A monitor created while its target is already down won't cry wolf — its first alert will be the recovery.
• A public status page (unguessable URL, shows the hostname only), an embeddable README badge and an Atom feed of its down/recovered events — see §5.

3. Alert formats

The payload shape is picked from the webhook host, because Slack and Discord reject arbitrary JSON:

• hooks.slack.com → {"text": "🔴 … went DOWN — HTTP 503. Two consecutive checks failed."}
• discord.com/api/webhooks/… → {"content": "…"}
• Anything else → JSON, HMAC-signed with your monitor's secret:

POST /your/endpoint HTTP/1.1
x-mockbird-signature: sha256=dffca4c76dc0357edf0ce208e27b5151fa66bab7d…

{"id":"evt_…","event":"service.down","monitor":"mon-d7c62042fa",
 "checked_url":"https://api.example.com/health", … }

Verify it like a Stripe/GitHub webhook — HMAC-SHA256 over the raw body:

import hashlib, hmac
def verify(raw_body: bytes, header: str, secret: str) -> bool:
    expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, header)

The signed-JSON path is what makes this agent- and CI-friendly: a script (or an AI agent) can subscribe its own health endpoint with one POST, receive machine-readable down/up events, and verify authenticity — no OAuth app, no dashboard session.

4. Check on it, stop it

# uptime info: latest check, 24h ok-rate, recent down/up transitions, delivery status
curl "https://mockbird.mockbird.workers.dev/api/status/monitor/mon-d7c62042fa?secret=YOUR_SECRET"

# stop monitoring (removes the monitor and its history)
curl -X DELETE "https://mockbird.mockbird.workers.dev/api/status/monitor/mon-d7c62042fa?secret=YOUR_SECRET"

The info response includes ok_rate_24h, the last 24h of checks, the alert channel's delivery health (fail_streak — after 5 consecutive failed deliveries the alert and monitor are removed rather than left rotting), and the monitor's public status_page / badge_svg / feed_atom URLs.

4½. No webhook? Poll mode

If you don't have a webhook endpoint handy (scripts, CI, agents), just omit notify on create. You get a pollable monitor instead: the create response includes a poll URL, and

curl "https://mockbird.mockbird.workers.dev/api/status/monitor/mon-…/poll?secret=YOUR_SECRET"

returns the down/recovered transitions since your last poll plus the latest check — empty events means nothing changed. Same debounce as the webhooks; checks still run every 30 minutes, so polling more often can't see anything new. The same works for heartbeats (/api/status/heartbeat/hb-…/poll): missed-check-in / checked-in-again transitions plus the current ping age. Pollable monitors nobody has polled for 30 days are removed (a heartbeat that's still being pinged stays alive regardless).

5. Public status page, README badge + Atom feed

The create response includes status_page, badge_svg and feed_atom. The page (/status/mon-…) shows live state, 24h/7d OK-rates, recent checks and down/recovered events; the badge is a shields-style SVG that re-renders from the latest check (cached 5 min):

[![api.example.com status](https://mockbird.mockbird.workers.dev/status/mon-d7c62042fa/badge.svg)](https://mockbird.mockbird.workers.dev/status/mon-d7c62042fa)

Drop that in a README, an internal wiki, or a runbook — anyone can see whether the thing is up without asking you. The Atom feed (/status/mon-…/feed.xml) carries the same debounced down/recovered events as the webhook — point an RSS reader or a feed-watcher at it if a webhook is more plumbing than you want. Privacy: both URLs contain the unguessable monitor id and show only the hostname; the full monitored URL, the alert webhook, and management actions still require the secret. Deleting the monitor kills the page, badge and feed.

6. Cron jobs: heartbeat monitoring (the inverse)

Polling a URL can't tell you whether your nightly backup ran. For scheduled jobs the model flips: your job pings us, and the alert fires when the ping stops — a dead man's switch, same idea as healthchecks.io:

curl -X POST https://mockbird.mockbird.workers.dev/api/status/heartbeat \
  -H 'content-type: application/json' \
  -d '{"name":"nightly backup","period_minutes":1440,"notify":"https://hooks.slack.com/services/T000/B000/XXXX"}'

The response includes a secret ping_url (/ping/p-…). Append it to the end of the job:

# crontab
15 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 https://mockbird.mockbird.workers.dev/ping/p-…

If no ping arrives within period_minutes + grace (defaults to half the period; override with grace_minutes), your webhook gets one service.down ("missed its check-in"), and one service.up when pings resume. Same Slack/Discord/HMAC-signed formats as everything above. Evaluation runs every 30 minutes, so this is for cron jobs, not sub-minute liveness (period_minutes 30–10080). Heartbeats get the same public status page, README badge and Atom feed as URL monitors — and the ping URL is a separate secret that never appears on any of them, so an embedded badge can't let anyone fake check-ins. Creation counts as the first ping. Limits: 5 live heartbeats per IP — deleting one frees the slot immediately. Full usage: GET /api/status/heartbeat — or the dedicated walkthrough: cron-job monitoring with one curl.

7. Bonus: alerts for APIs you depend on

If the URL you care about is a public developer API — JSONPlaceholder, ReqRes, httpbin, DummyJSON and 49 others we already track — you don't need a monitor slot at all. Subscribe to the tracker's own checks:

curl -X POST https://mockbird.mockbird.workers.dev/api/status/watch \
  -H 'content-type: application/json' \
  -d '{"service":"reqres","url":"https://hooks.slack.com/services/T000/B000/XXXX"}'

Use "service": "*" to watch all 52 at once. Same formats, same debounce, same no-account deal. Full usage: GET /api/status/watch.

8. Honest comparison

This is deliberately not a monitoring dashboard product, and for plenty of situations the incumbents are the better pick. (We build mock APIs; the monitor exists because our status tracker already had the machinery.) Facts below checked September 2026 — verify current pricing yourself:

Where the incumbents win, plainly: faster checks (5 min vs our 30), email/SMS/push channels, keyword/port/SSL-expiry checks, richer status pages (custom domains, incident posts), dashboards, teams. We do: HTTP GET, webhook on transition, a minimal live status page + badge, zero setup friction.