Changelog

The zero-signup instant check now has a home of its own: /check. Paste a URL, get a real answer from the network edge — final HTTP status and response time — with no account and no JavaScript required. Results live at a shareable URL (/check?url=…), so “it’s down for me too” is now a link you can paste into the team chat. Same engine and safety rules as GET /api/check; one click turns any result into a free every-60-seconds monitor.

Watchpup’s MCP server is now published in the official Model Context Protocol registry as dev.workers.watchpup.watchpup/watchpup — MCP clients and directories that browse the registry can discover and connect to https://watchpup.watchpup.workers.dev/mcp without any manual config hunting. Same 12 tools, same endpoint; domain ownership proven cryptographically at /.well-known/mcp-registry-auth. Docs.

A new guide, Give your AI agent eyes on production: why agents need an outside monitor (an agent can’t see its own loop die), what the MCP server’s 12 tools do, the one config block to connect Claude Code / Cursor / Claude Desktop, and patterns worth stealing — heartbeat your agent loop, create monitors at deploy time, hand investigation agents a read-only key, ack + annotate incidents through the agent.

Watchpup now speaks the Model Context Protocol natively at POST /mcp — point Claude Desktop, Claude Code, Cursor, or your own agent at it and it gets 12 tools: create, update, pause and delete monitors, read and acknowledge incidents, attach postmortem notes, list alert channels, read any public status page, and instantly check any URL. Streamable HTTP, stateless — auth is just your API key in a header, no OAuth dance. The check_url and get_status_page tools work with no key at all, and every other tool answers with signup instructions until a key is configured, so an agent can bootstrap its own account end-to-end. Tool calls run through the same validation, rate limits and read-only-key rules as the REST API, and mutations appear in your activity log tagged mcp. Docs.

A new Guides section: evergreen, practice-first articles on the monitoring problems that actually bite — catching silently failing cron jobs, TLS-certificate expiry, domain-registration expiry, doing website uptime checks properly, and setting up a public status page. Each one covers the failure modes and the vendor-neutral fix first, then the concrete free Watchpup setup. Corrections welcome by email, as always.

The privacy page claimed Watchpup sets exactly one cookie. Since password-protected status pages shipped, that has been wrong: unlocking a protected page sets a second, signed wp_sp_<page> cookie (HttpOnly, 30 days) so you don’t retype the password every visit. The page now says so. It proves you entered the password and nothing else — no tracking, same as before; only the description was out of date.

Creating a monitor no longer demands a name — leave it out and Watchpup names it after what it watches: the URL host for HTTP checks, the target for TCP/TLS/DNS/domain monitors ("db.example.com:5432", "example.com MX"). One less required field between you and a running check, in the API, the dashboard form, and the CLI alike. Heartbeat monitors still need a name — a dead-man’s switch is identified by what job it stands for. Rename any monitor later with PATCH /api/monitors/{id} {"name":…}.

Password hashes (accounts, team members, and protected status pages) are now derived with 3× more PBKDF2-SHA-256 work than before, and every stored hash is versioned with its work factor — so the cost can keep rising as hardware gets faster without ever invalidating your login. Existing passwords keep working and upgrade to the new strength the next time they’re set or changed. No action needed.

Every Watchpup response now carries standard hardening headers: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Strict-Transport-Security, and — on app pages — frame-ancestors 'none' so nothing can clickjack your dashboard or login. Public status pages deliberately stay frameable: embedding one full-page in an <iframe> on your own site is now a documented feature. Docs.

Status pages can now show your service-level promise being kept — opt a page in with Show SLA status (its manage panel, or PATCH /api/status-pages/{slug} {"show_sla":true}) and every monitor on it that has an SLA target displays its month-to-date state publicly: “🎯 SLA target 99.9% — 99.97% this month · within error budget”, turning red when the budget is spent. The same summary lands in /s/{slug}.json as an sla object, so your own dashboards can consume it. Off by default — your targets stay private until you choose to publish them; paid status-page products sell this as “SLA display”. Docs.

HTTP monitors can now require a response header: set header_name and the check fails the moment that header disappears — add header_expect and it also fails unless the header’s value contains that string (case-insensitive, so application/json matches application/json; charset=utf-8). A 200 with the wrong content-type is usually an error page wearing a success code; a vanished strict-transport-security or CORS header is a misconfiguration your users hit before you do. Alert details name the actual value seen. Set it on create, in the monitor page’s Check settings, or by PATCH /api/monitors/{id}; it rides backup and restore like every other check rule. Docs.

Watchpup now serves an RFC 9116 security.txt (also at /security.txt): a machine-readable contact for security researchers. If you spot a vulnerability, that file tells you exactly where to write — reports are read and acted on. A small thing, but a monitoring service asks you to trust it with endpoints and alert hooks, so the front door for security reports should be standard and easy to find.

Escalation delays got a second dial: alongside the per-channel delay_s, monitors now take an alert_delay_s — every alert channel waits at least that long before hearing that monitor’s down alert, and if it recovers first, nobody hears anything (no down, no recovery, no reminders). Per-channel answers “who may be woken, and how fast”; per-monitor answers “how twitchy is this endpoint” — a known-flaky third-party API can wait ten minutes on every channel while your own services still page instantly, no channel settings touched. The two stack: the longer delay wins. Set it in the monitor page’s new Alert delay panel, on create, by PATCH /api/monitors/{id}, or watchpup delay ID 10m; it round-trips through backup and restore. Docs.

The comparison page gained two rows for things we shipped but never listed: scheduled maintenance windows (free here, one-off and repeating, announced on status pages ahead of time with subscriber heads-up emails — a paid-plans-only feature at UptimeRobot per their own help center, a daily per-monitor window at Better Stack, and manual pause only at Healthchecks.io) and the maintenance calendar (ICS) your users can subscribe to — which none of the three offer (Better Stack’s status-page subscription options are email, webhook, RSS and JSON, per their own docs). Facts re-verified against each vendor’s public pages on 29 July 2026; corrections welcome and ship same-day.

With team members sharing an account, “who deleted that monitor?” needs an answer. Every change is now recorded automatically — monitors added, edited or deleted, alert channels, status pages, maintenance, team invites and removals, sign-ins, password/key/2FA changes, imports and restores — with who did it, whether it came from the web dashboard or an API key, and what was touched. Privacy is designed in: for edits only the names of changed fields are recorded, never the values, so a pasted bot token can’t end up in the log. Recent activity shows in Settings; the full log is at GET /api/audit and watchpup audit in the CLI. Kept 90 days, visible to the whole team, deleted with the account — and it covers every future endpoint automatically, because it’s recorded at the API boundary rather than sprinkled through the code. Docs.

Every public status page now serves /s/{slug}/maintenance.ics: an iCalendar feed of all active and upcoming maintenance windows covering that page. Your users (or your own team) subscribe once in Google Calendar, Apple Calendar, Outlook — anything that speaks ICS — and every window you schedule simply appears in their calendar, with your note, scope and a link back to the status page. Repeating windows come through as real recurring events (RRULE), rescheduling updates events in place instead of duplicating them, and everything is marked “free” time so it never blocks anyone’s availability. Linked from every status page footer and from the 🔧 Maintenance panel; password-protected pages keep their calendar private too. Docs.

The free-plan comparison gained a row for yesterday’s escalation delays. Facts from each vendor’s own public pages today: UptimeRobot’s “if down for x minutes” notification option is a Pro-plan feature per their FAQ; Better Stack has escalation policies with wait-steps (escalating to on-call responders uses paid responder seats); Healthchecks.io alerts are immediate and one-shot — grace time tunes when a check counts as down, not which channel hears about it. Spot an out-of-date fact and it ships fixed same-day.

Give any alert channel a delay — {"delay_s":300} — and it only hears about outages that outlast it: the down alert is held and delivered only if the monitor is still down when the delay ends. If the service recovers first, that channel gets nothing — no down, no recovery, no reminders — while your immediate channels still record the blip. Classic setup: email and Slack alert instantly, the phone push (Telegram/ntfy) waits five minutes — a one-minute deploy hiccup never buzzes a pocket at 3am, a real outage still does. Per channel, so you build a simple escalation ladder without an on-call product: chat now, phone at 5 minutes, boss’s phone at 30. Set it from each channel’s delay button in Settings, watchpup channels delay ID 5m, or PATCH /api/channels/{id}; only down alerts are delayed — slow/fast/budget notifications are not. Quiet hours stack on top. Docs.

The free-plan comparison gained two rows for features we’d shipped after the table was built: incident acknowledgements (pause the still-down reminders while you fix — free here; Better Stack has acknowledge in its incident flow, UptimeRobot and Healthchecks.io show no equivalent) and per-channel quiet hours (alerts held and delivered when the window ends, with down alerts optionally breaking through — we found no per-channel equivalent on any of the three; Better Stack’s time-based control is on-call scheduling, which is paid). Facts checked against each vendor’s own public docs today; corrections ship same-day.

A job that succeeds in 50 minutes instead of 5 is an outage in the making, and a dead-man’s switch alone will never mention it. Heartbeat monitors now take a max_duration_s limit: any measured run (one that uses the start signal) that finishes over the limit fires the 🐢 alert immediately — one slow run is signal when runs are scheduled, so there’s no 3-strike wait — and the next run back under the limit sends the ⚡ recovery. The monitor stays up: this is a warning, not downtime. Set it in the new Run duration limit panel on the monitor page, on create, or by PATCH; alert routing, quiet hours and delivery retries apply as with every alert, the dashboard shows the 🐢 tag, the Prometheus watchpup_monitor_slow gauge covers it, and the weekly digest calls out “over its limit” runs. Grace catches runs that never finish; this catches the ones that finish too slowly. Docs.

Heartbeat monitors that use the start signal already measure how long each run takes; the Monday digest now includes it — each such heartbeat’s line gains “last run took 12s” (or “under a second”). One glance at the weekly email answers both “did my backups run?” and “are they getting slower?”. Preview yours with curl /api/digest/preview.

Restoring a backup into a live account is the kind of thing you want to see coming. Add ?dry_run=1 to POST /api/import/watchpup (or watchpup restore FILE --dry-run, or the new Preview button next to Restore on the dashboard) and you get the exact per-item report a real restore would produce — what would be created, what already exists, what would fail and why, which routing entries would be dropped — with nothing created, no emails sent, and the real restore rate limit untouched. Same code path end to end: reads hit the database, writes are swallowed. Docs.

Since day one you could download your whole account as one secret-free JSON file (/api/export). Now you can feed it back: POST /api/import/watchpup, watchpup restore FILE in the CLI, or the new panel on the dashboard. It restores alert channels, then monitors (full configuration, tags, thresholds, paused state — and alert routing remapped onto the restored channels), then status pages (monitor lists, groups and branding), then active maintenance windows — silently, with no subscriber notices. Idempotent, so re-running is safe: anything that already exists is skipped. Honest limits, because backups carry no secrets: webhook channels get new signing secrets, Telegram channels and page passwords must be re-added by hand, and subscribers have to opt in again. Undo an accidental delete, clone your setup to a second account, or leave and come back — your config is portable both ways. Docs.

API keys end up in places you don’t fully control — Prometheus scrape configs, Grafana data sources, CI dashboards, a shared jump box. Every account now has a second key, wp_ro_… (in Settings next to your full key), that reads everything through the same API but is refused with a 403 on any change — and it never reveals your full key, webhook signing secrets or Telegram bot tokens. The CLI’s read commands (ls, status, watch, incidents, backup…) work with it as-is. Rotate either key independently. Same wake, related fix: the account backup now masks Telegram bot tokens in channel targets — it always promised to be secret-free, and now it fully is. Docs.

The free-plan comparison was re-verified against each vendor’s current public pricing and docs today. Two corrections — both places where we’d been underselling ourselves: UptimeRobot’s SSL-certificate and domain-expiry monitoring are paid-plan features per their own knowledge hub (we’d marked them free), and the table now has a DNS-record-monitoring row (Watchpup: 8 record types with value matching, free). The standing offer stands: spot an out-of-date fact on that page and it gets fixed same-day.

A dead-man’s switch that only notices silence makes you wait out the schedule to learn a job died. Now the job can just say so: hit /ping/<id>/fail and the monitor goes down and alerts immediately — POST the error output and it becomes the incident detail your alerts and status page show. And report /ping/<id>/start when a run begins: if success or failure doesn’t follow within the grace time, that’s a hung job, caught within minutes instead of at the next schedule slot — plus Watchpup starts measuring how long your runs take (last_duration_s in the API, “last run took…” on the monitor page). Three-line crontab pattern: curl …/start; my-job.sh && curl …/ping || curl …/ping/fail. Also in the CLI: watchpup ping ID [start|fail]. Docs.

Down reminders exist to nag until someone acts; now there’s a way to say “someone is.” Hit ack on an ongoing incident (the DOWN event on the monitor page, watchpup ack <id>, or POST /api/incidents/<id>/ack) and the “still down” reminders go quiet while you work — the initial down alert and the recovery alert are untouched, and un-acking (or the monitor recovering) re-arms everything. Who acked and when is recorded for your team — in GET /api/incidents, on the monitor page and in watchpup incidents — but never published: your public status page stays for incident updates, not internal ops chatter. Team members can ack too. Docs.

The team list now tells you when each member last logged in — in Settings, in GET /api/members (last_login), in watchpup team and in the account backup export. Accepting the invite and completing a password reset count as logins; pending invites show when the invitation email went out instead. Handy for the oldest team-hygiene question there is: is anyone actually using that seat?

If your monitors carry tags, the Monday digest email now groups them under tag headers — each with its own uptime figure — instead of one long flat list. Web, infra and cron jobs read as separate sections at a glance. A monitor with several tags appears once (under its alphabetically-first tag), untagged monitors stay at the top, and accounts that don’t use tags see exactly the email they got before. Preview yours any time: curl /api/digest/preview with your API key. Docs.

This page ships daily, so it deserves a subscription: /changelog.xml is an Atom feed of everything here — drop it in your feed reader (Miniflux, Feedly, Thunderbird, anything that speaks Atom or RSS) and new Watchpup features come to you. Same pattern as the per-status-page incident feeds that have existed since launch, now for the product itself.

Yesterday incidents got a live timeline; today the people who asked to be kept in the loop get it delivered. Posting an update on an incident now also emails the verified subscribers of every status page showing that monitor — the update text, its stage (investigating → identified → monitoring → resolved), and where the incident stands, with one-click unsubscribe as always. Sensible guardrails: only ongoing incidents and ones resolved less than a day ago notify (a postmortem posted right after still lands; editing ancient history emails nobody), capped at 20 notified updates per day. Nothing to configure — if you post updates and people subscribed, they now hear from you. This is the other half of what the big status-page vendors charge for. Docs.

When something breaks, the most important thing a status page can say is “we know, and here’s where we are.” You can now post timeline updates on any incident — investigating → identified → monitoring → resolved — and they publish chronologically with the incident on your public status pages, in /s/<slug>.json and the Atom feed. Visitors watching your status page during an outage see each new update within ~30 seconds, no reload — and the ongoing-incident row shows the latest stage at a glance. Post from the + update button next to any DOWN event, POST /api/incidents/<id>/updates, or watchpup update <id> investigating "…"; team members can post too. The big status-page vendors sell exactly this — here it’s free. Docs.

Who watches the watcher? Now there’s an answer you can check: /status is Watchpup’s own live health page — whether the check loop is running on schedule, its measured reliability over the last 24 hours, and how many checks and alert events it has processed. Self-measured and honest about the one caveat that implies (if we were completely down, the page wouldn’t load either — everything short of that shows up in the numbers). Machine-readable at /status.json, so you can even point a monitor at your monitoring.

Already have your cron jobs wired up at Healthchecks.io (or a self-hosted Healthchecks instance)? One API call — or the new panel on the dashboard — brings them all over: simple checks become interval heartbeats, cron checks keep their exact schedule and timezone (both of which Watchpup speaks natively), and your tags come along for the ride. The project’s read-only API key is enough, it’s used for a single read and never stored, and re-running is safe — checks you already imported are skipped. POST /api/import/healthchecks, or paste your key on the dashboard. Docs.

Yesterday status pages learned to announce maintenance ahead of time — now your terminal does too. watchpup status lists active windows (🔧 scope, end time, note, repeat) and anything starting in the next 24 h, and watchpup watch carries a live maintenance banner plus an until HH:MMZ tag on each monitor that’s currently quieted — so a wall display never leaves you guessing why a check went blue or when it comes back. No new commands to learn; re-download /cli to update.

Until now a maintenance window was invisible to status-page visitors until it started. Now every public status page gets a 🔧 Maintenance panel listing active and upcoming (next 7 days) windows — start/end times, how long until it starts or ends, your note, and whether it repeats. Account-wide windows show on all your pages; monitor-scoped ones only where that monitor appears. Machine-readable as scheduled_maint in /s/{slug}.json, and open status pages refresh in viewers’ browsers within ~30 s of you scheduling or cancelling a window — no reload needed. Schedule from the dashboard, watchpup maint add, or POST /api/maintenance. Docs.

Dead links now land on a proper 404 page with a way back to your dashboard, the docs and the changelog instead of a bare error line. And the comparison page gained a team-seats row, re-verified against each vendor’s current public pricing: extra logins are free here (up to 10) and on Healthchecks.io (unlimited, since Feb 2026), free-with-caveats on Better Stack (members free, on-call responders paid), and paid-plan-only on UptimeRobot. As always: spot an out-of-date fact there and it gets fixed same-day.

Uptime is a team sport, so stop sharing passwords: invite up to 10 teammates to your account, each with their own login. Members manage the same monitors, status pages and alert channels you do, while your credentials, API key, 2FA, the team list and account deletion stay owner-only. Invites are emailed with a one-click accept link; removing a member logs them out instantly. Seats are where most monitoring tools reach for your wallet — here they’re part of the free product. Invite from the new Team panel in Settings, watchpup team add teammate@example.com, or POST /api/members. Docs.

The terminal catches up with the dashboard’s tag filtering: watchpup status tag=prod gives you a one-line summary (and scriptable exit code) for just the monitors carrying a tag, and watchpup watch tag=prod keeps a live table of only that slice on screen — handy on a wall display per environment or per client. Comma means must-carry-all (tag=prod,eu-west), bare form works too (watchpup status prod), and watch takes the refresh interval and the filter in any order. Re-download /cli to update.

Status pages can now maintain themselves by tag: set auto_include_tag to e.g. public and the page always shows every monitor carrying that tag — current and future. Tag a new monitor public and it appears on the page; untag it and it’s gone. The middle ground between auto-include-everything and hand-picked lists: one page per environment or per client, driven by the tags you already use for filtering. Down/up and maintenance emails to that page’s subscribers follow the tag scope too. Set it in the page’s manage panel on the dashboard, watchpup pages set acme autotag=public, or PATCH /api/status-pages/acme {"auto_include_tag":"public"} ("" turns it off and freezes the currently matching set). Docs.

Your whole account in one JSON file: GET /api/export (or watchpup backup in the CLI, or the new Your data link in Settings) downloads every monitor with its complete configuration in the same shape the API uses, your alert channels, status pages with their subscribers, maintenance windows, 90 days of down/up events with incident notes, and 90 days of per-day uptime/latency stats. Deliberately secret-free — no API key, password hashes, webhook signing secrets or 2FA material — so the file is safe to keep as a backup or feed to your own tooling. We’d rather you never feel locked in than lock you in. Docs.

Fifteen monitors across three environments gets messy fast — so label your monitors with tags (prod, api, eu-west… up to 10 each) and filter everything by them. Tag pills on the dashboard are clickable filters (the live view keeps auto-updating within the filtered set), GET /api/monitors?tag=prod filters the API (comma = must carry all listed tags), and the CLI gets watchpup ls tag=prod plus watchpup tag ID prod,api to set them. Add tags from the add-monitor form, each monitor page’s new Tags panel, or the API — also on bulk import. Docs.

Status pages for audiences that aren’t the whole internet: set a password on any status page and visitors get an unlock form instead of your uptime data — for internal dashboards, client-only pages and staging environments. The right password sets a signed 30-day cookie for that browser; changing or clearing the password locks everyone out again instantly, and you always see your own pages while logged in. The page’s JSON, Prometheus metrics, Atom feed, embed widget and subscribe form are locked too (401 for strangers, normal for unlocked visitors), protected pages are noindex’d, and unlock attempts are rate-limited. Set it in each page’s manage panel on the dashboard, watchpup pages set acme password=…, or PATCH /api/status-pages/acme {"password":"…"} ("" makes it public again). Docs.

New dns monitor kind: watch any DNS name — subdomains and underscore names like _dmarc.example.com included — and alert when it stops resolving (NXDOMAIN, SERVFAIL), the record type you care about disappears, or no record matches an expected value. Catches botched DNS migrations, dropped MX records, hijacked CNAMEs and DNSSEC breakage, usually before your HTTP checks notice. A, AAAA, CNAME, MX, TXT, NS, SRV and CAA records; checked every 5 minutes by default via Cloudflare’s DNS-over-HTTPS resolver. Value matching is forgiving where DNS is messy: case and trailing dots ignored, TXT matches on contains (SPF/DKIM-friendly), MX/SRV accept just the target host. Add one from the dashboard, watchpup add dns example.com MX expect=mail.example.com, or POST /api/monitors {"kind":"dns",…}. Docs.

The add-monitor form’s hidden TLS row was clobbering the TCP host:port field on submit, so browser-side TCP adds failed validation (the API and CLI were unaffected). Fixed — and the same fix covers the new DNS row.

Two more places alerts can land, zero glue required: {"kind":"teams"} posts to a Microsoft Teams channel — paste a Workflows webhook URL (the modern …logic.azure.com kind Microsoft moved everyone to; we send the Adaptive Card format it expects) or a legacy connector URL (plain text, still works where tenants have it) — and {"kind":"googlechat"} posts to a Google Chat space’s incoming webhook. Add them from Settings, watchpup channels add teams …, or the API, then hit test. Delivery retries, quiet hours, per-monitor routing and channel health all apply like any other channel. Teams setup · Google Chat setup.

Alerts where half the internet already talks: point an alert channel at your own Telegram bot and down/up/slow/SLA notifications land in any chat, group or channel — free push on every platform Telegram runs on, no phone-number sharing with us and no third-party service in between. One-time setup: make a bot with @BotFather, get your chat id, add a channel with target BOT_TOKEN/CHAT_ID (Settings, watchpup channels add telegram …, or the API), then hit test. Delivery retries, quiet hours and per-monitor routing all apply like any other channel. Docs.

Alerts no longer have to go everywhere: route each monitor to specific alert channels — the production API pages the on-call webhook, the staging box just emails you. Set it from the new Alert-routing panel on any monitor page, watchpup route ID 1,3 in the CLI, or {"channels":[1,3]} on monitor create/PATCH (null = all channels, the default; [] = mute the monitor’s alerts entirely — flagged 🔕 on the dashboard so you can’t forget). Applies to every alert type including reminders and SLA-budget warnings; status pages and their subscribers are unaffected. Deleting a channel cleans it out of routing lists automatically. Docs.

Per-channel do-not-disturb: give any alert channel a quiet window — {"quiet":"22:00-07:00","quiet_tz":"Europe/Berlin"} — and nothing rings there until the window ends. Held alerts aren’t dropped: they’re delivered when quiet ends, with the original event details and timestamp, so the morning catch-up tells you exactly what happened overnight. Set quiet_down: true and down/recovery alerts still break through — quiet then only silences the informational slow/fast/budget noise. The window is wall-clock in the timezone you pick (daylight saving handled), may wrap past midnight, and is per channel: your phone’s ntfy push can sleep while the team webhook keeps firing. Configure it from each channel’s quiet button in Settings, watchpup channels quiet ID 22:00-07:00 tz=Europe/Berlin, or PATCH /api/channels/{id}. Docs.

Stop guessing latency thresholds: set slow_ms to auto and Watchpup learns one from the monitor’s own behavior — 2× its median response time over the last 24 hours, re-learned every hour so it tracks what “normal” actually is for that endpoint. Three consecutive checks over the learned line fire the usual 🐢 alert (which names the threshold it used), three back under send the ⚡ recovery. Works for HTTP and TCP monitors, from the add form, each monitor’s Check settings, or the API — auto_threshold_ms shows the current learned value. Needs ~20 successful checks before it arms, and never alerts under 200ms. Docs.

Cron heartbeat schedules can now run in any IANA timezone: {"cron":"0 3 * * *","tz":"Europe/Berlin"} means 03:00 Berlin wall clock, year-round — daylight-saving shifts are handled for you, so the schedule tracks what your crontab actually does instead of drifting an hour twice a year. A wall time skipped by spring-forward is simply missed that day; a repeated fall-back time counts once. Set it on the add form, the monitor’s Schedule panel, watchpup add heartbeat … tz=Europe/Berlin, or the API; missed-run alerts and next_due report in the schedule’s zone. Docs.

Heartbeat monitors can now carry the job’s real cron schedule ("cron":"0 3 * * *", UTC) instead of a fixed interval — Watchpup expects a ping after every scheduled run, so a nightly backup that skips its 03:00 slot alerts that morning, not an interval-guess later. Standard 5-field syntax with ranges, lists, steps and @daily-style aliases; the API also reports next_due, the unix time of the next expected ping.

Yesterday’s monitor groups are now scriptable without touching raw JSON: watchpup pages group SLUG shows which section every monitor on a page renders in, pages group SLUG MONITOR-ID "API" puts a monitor in a group, … MONITOR-ID --clear ungroups it and … --clear-all resets the page. The API replaces the whole mapping on every PATCH, so the CLI does the read-merge-write dance for you — one monitor at a time, nothing else disturbed. Re-download /cli to update.

Status pages can now be organized into sections — group your monitors under headings like “API”, “Websites” or “Background jobs”, each with its own worst-status dot, the way the paid status-page products do their “component groups”. Set a group per monitor in the dashboard’s manage panel, or via PATCH /api/status-pages/{slug} {"groups":{"<monitor_id>":"API"}}; ungrouped monitors stay on top, and /s/{slug}.json reports each monitor’s group. Docs.

Yesterday’s dashboard trend arrows are now data you can script against: GET /api/monitors/{id} returns trend_1h — average response time over the last hour vs the hour before, with a rounded percent change and a slower/faster/steady verdict at the same ±15% threshold the arrows use. watchpup latency ID prints it as a trend line under the percentiles. Null until both hours have a few successful checks, so quiet monitors stay quiet. Docs.

The dashboard now flags latency drift before it becomes a slow alert: HTTP and TCP monitor rows show ↗ (amber) when average response time over the last hour is at least 15% worse than the hour before, and ↘ (green) when it’s at least 15% better. Hover the arrow for the exact averages. Needs a few checks in both hours; steady monitors stay clean — no arrow, no noise.

The per-slice details on the 24-hour check bars and 90-day uptime history bars (date, uptime %, failed-check counts) were hover-only tooltips — invisible on phones and tablets. Now tapping any bar cell, on status pages and monitor pages alike, pops the same detail in a small bubble; tap again or anywhere else to dismiss. Desktop hover unchanged.

The embeddable status pill can now match its surroundings: <script src="…/embed.js" data-theme="auto"> renders light or dark to match each visitor’s system preference — and switches live, no reload, if they flip it. data-theme="dark" and the default light pill are unchanged. Pairs with yesterday’s light-mode release so the pill, your site and your status page finally agree on a palette. Docs.

Watchpup now follows your system theme: every page — landing, dashboard, docs and, most importantly, your public status pages — renders in a clean light palette when your OS or browser prefers light, and stays in the familiar dark one otherwise. Charts, uptime bars, badges-on-page and custom status-page accent colors all adapt automatically; nothing to configure. Status pages you embed in front of light-mode visitors stop looking like a terminal at midnight.

watchpup channels now shows each alert channel’s delivery health inline: a channel whose last delivery failed gets an amber-style ⚠ tag with the exact error and how long ago (⚠ webhook endpoint answered HTTP 500 (4m ago)), clearing on the next successful delivery — the same signal as Settings and last_error in GET /api/channels, now greppable from a terminal or cron job. Re-download /cli to update.

A failed delivery is a lost alert — the one failure a monitoring tool must not shrug off. Watchpup now retries transient delivery failures (network errors, timeouts, HTTP 408/425/429/5xx) after 1, 5 and 15 minutes, for every channel kind including alert emails; webhook retries are re-signed with a fresh timestamp. Each channel also reports its delivery health: the last failure (and when) shows in Settings and as last_error/last_error_ts in GET /api/channels, and clears on the next successful delivery — so a channel that’s been quietly broken for a week can’t hide. Docs.

Your uptime monitor holds API keys, alert channels and status pages — it deserves a second lock. Settings now has a 2FA panel: scan-or-paste a standard TOTP secret into any authenticator app (Google Authenticator, Aegis, 1Password, …), confirm one code, save your 8 one-time recovery codes, done. Logins then need password + code; API-key access, badges and status pages are unaffected, and password-reset emails no longer auto-log-in on 2FA accounts. Also scriptable: watchpup 2fa on in the CLI or POST /api/2fa/setup → /enable. Docs.

Badges can now show tail latency, not just averages: ?metric=p95 (or p50/p90/p99) on any http/tcp monitor’s badge URL renders that percentile over the last 24h of checks, colored by your slow threshold like the response badge. Badge JSON gains p50/p90/p95/p99_ms_24h. A green average can hide an ugly p99 — now the badge can’t. Docs.

Scheduling maintenance no longer needs the dashboard: watchpup maint add 45m note=’DB upgrade’ quiets checks, alerts and downtime-counting for 45 minutes starting now; start=, monitor= and repeat=daily|weekly cover scheduled, scoped and recurring windows (watchpup maint add 30m start=2026-08-01T02:00:00Z repeat=daily = a nightly backup window, scheduled once). watchpup maint lists active/upcoming windows, watchpup maint rm ID cancels. Made for deploy scripts: open a window, deploy, let it expire. Re-download /cli to update.

You can now attach a short note to any incident — what happened, what you did about it — and it’s published with that incident on your public status pages, in /s/<slug>.json, the Atom feed and the weekly digest. Add it with the + note button next to any DOWN event on a monitor page, POST /api/incidents/<id>/note, or watchpup note <id> "…" from the CLI. The big status-page vendors gate incident updates behind paid plans; here it’s one button. Docs.

Maintenance windows can now repeat: add "repeat": "daily" or "weekly" to POST /api/maintenance (or pick it in the dashboard’s schedule form) and the window rolls forward to its next occurrence automatically when it ends — schedule your nightly backup job or weekly reboot once, cancel any time. Status-page subscribers get the heads-up email only when it’s first scheduled, never nightly. Details in the docs.

Webhook alerts are now authenticated: every webhook channel gets a whsec_… signing secret, and every POST Watchpup sends carries an X-Watchpup-Signature: t=…,v1=… header — an HMAC-SHA256 over the timestamp and the raw body, Stripe-style. Verify it in a few lines to be sure a payload really came from Watchpup and isn’t a replay; rotate the secret any time from Settings or POST /api/channels/<id>/secret/rotate. Verification snippets in the docs.

Every http/tcp monitor’s embeddable badge can now show average response time instead of uptime: add ?metric=response to the badge URL (?window=7d|30d work here too). If the monitor has a slow threshold set, the badge turns green under it and amber at or over it. Badge JSON gains avg_ms_7d/avg_ms_30d. Snippet on each monitor page, details in the docs.

Your check history was already exportable as CSV over the API; now the CLI wraps it: watchpup export 2 downloads every raw check (~3 days) for monitor 2 into a tidily named file, watchpup export 2 daily grabs ~90 days of daily uptime rollups, and watchpup export 2 daily - streams to stdout for piping straight into csvkit, sqlite3 or a spreadsheet. Re-download /cli to update.

Every status page now ships a one-line embed: <script src="…/s/your-slug/embed.js" async></script> renders a small live pill on your own website — “All systems operational”, “2 services down”, or “Under maintenance” — linking to your status page and refreshing itself once a minute. Floating corner or inline, light or dark, ~2 KB, zero dependencies. Copy the snippet from the dashboard’s “manage” panel or see the docs.

Watchpup now has a plain-language privacy page (what is stored, for how long, and how to delete every byte yourself — spoiler: no trackers, no ad scripts, one session cookie) and short terms of use (monitor only what you’re authorized to monitor; your data is exportable and deletable). Linked from every page footer.

HTTP and TCP monitor pages now show a 24-hour response-time chart: an average line per 30-minute bucket, a shaded min–max band so you can see jitter at a glance, red ticks marking buckets that contained failed checks, and hover tooltips with exact numbers. Rendered as plain inline SVG — no JavaScript, no external assets.

The CLI can now run your public status pages end-to-end: watchpup pages lists them, pages add "My services" --auto creates one that always shows all your monitors, pages set myservices title=… auto=on|off monitors=ID,ID accent=#ff8800 logo=https://… edits everything the dashboard can, and pages subs myservices lists (or removes) the page’s email subscribers. Re-download /cli to update. Also fixed: watchpup signup printed a dashboard link that 404’d.

The landing page now links a real, running demo status page — an ordinary Watchpup status page watching Wikipedia, a TCP port, a TLS certificate, a domain expiry and a cron-job heartbeat. What you see there is exactly what your own page looks like: no mockups, no screenshots.

The dashboard now updates itself: it quietly re-checks your monitors every 30 seconds while the tab is open and refreshes the moment anything goes down, recovers, turns slow, or is added or removed from another device or the CLI. It never refreshes while you are typing in a form — it waits until you click away. Public status pages have worked this way since launch; now the logged-in view does too.

The CLI now manages alerting end-to-end: watchpup channels lists your channels, channels add ntfy https://ntfy.sh/topic (or email/discord/slack/webhook) creates one, watchpup test 3 fires a real test alert through it, and watchpup latency 2 prints 24-hour p50/p90/p95/p99 response times for a monitor. Re-download /cli to update.

Every alert channel in Settings now has a test button (API: POST /api/channels/<id>/test) that sends a real notification through it immediately. Delivery problems are reported back instead of silently eaten — a wrong webhook URL answers with its HTTP status, unreachable targets say so. Verify your alerting works before the 3am incident, not during it. Docs.

Settings gained a Change-password form (also POST /api/password/change and watchpup passwd in the CLI). It requires your current password even on an authenticated call, logs out every other browser session, and voids outstanding reset links — so a stolen cookie cannot quietly take over the account. Docs.

Leaked a key in a repo or log? POST /api/key/rotate (or the Rotate button in Settings, or watchpup key rotate in the CLI) issues a fresh key and kills the old one instantly. Docs.

Sharing any Watchpup page — including your public status pages — on Slack, Discord, Bluesky or X now renders a proper preview card: Open Graph/Twitter meta tags with per-page descriptions and a generated 1200×630 preview image, plus canonical URLs and a sitemap for search engines. Also fixed: validation errors in the monitor-page settings panels were being written to a hidden element — they now show up properly.

HTTP monitors can now require a field in a JSON response — json_path (data.items[0].state style) must exist, and with json_expect must equal an exact value. No more regex-ing {"status":"ok"} with a keyword: if the body stops being valid JSON, the field disappears, or the value changes, you get an alert naming the actual value. Docs.

Averages hide tail latency. http and tcp monitors now report 24-hour p50/p90/p95/p99 response times (plus min/max) — on the monitor page, as latency_24h on GET /api/monitors/{id}, and as p50_ms_24h/p95_ms_24h in the public status-page JSON. Docs.

The CLI gained a watch mode — watchpup watch redraws a color-coded table of all your monitors (down first, latency, last-checked) every 10 seconds until you ctrl-c. Like top(1), but for your services. Re-download /cli to update.

HTTP monitors can now send up to 10 custom request headers (Authorization, X-Api-Key, your own User-Agent, …), use any method (GET/HEAD/POST/PUT/PATCH/DELETE/OPTIONS) and attach a request body — so you can watch endpoints behind auth and POST-style health checks. Safety built in: if a redirect leaves the original host, Authorization/Cookie headers are dropped before following, so your token never reaches a third-party site.

The service now serves its own command-line client at /cli — a single dependency-free bash script. watchpup signup, watchpup add https://example.com, watchpup ls, watchpup status (exit code 1 if anything is down — script it!), watchpup incidents, and a raw watchpup api escape hatch for everything else.

Set renotify on a monitor (or use the Down reminders panel) and every alert channel gets a reminder at that interval until the monitor recovers — one 3am alert is easy to sleep through. Webhook event monitor.still includes down_since and down_for_s.

An honest, sourced comparison of Watchpup vs UptimeRobot, Better Stack and Healthchecks.io free plans — including where they beat us.

New tls monitor kind: daily certificate check on any TLS port (default 443). Alerts when a cert is expired, not yet valid, or inside your warning window (default 14 days), with the issuer named in the alert. Works on self-signed certs too. Cert expiry date and days-left surface on status pages, the status-page JSON and Prometheus metrics.

Set an sla_target (e.g. 99.9) on a monitor and your alert channels get notified once at 75% and once at 100% of the monthly downtime budget. Heartbeat downtime now correctly burns budget and shows on badges.

Per-monitor SLA target with a live burn-down bar: allowed / used / remaining downtime this calendar month, in the API, dashboard and authed Prometheus scrape.

Every heartbeat monitor gets its own ping email address — anything that can send mail (backup tools, RAID controllers, cron MAILTO) can now check in. Delivered mail counts as a ping within about a minute.

The landing page (and GET /api/check?url=…) checks any public URL on the spot; one click then turns it into your first monitor at signup.

POST /api/import/uptimerobot with a read-only API key migrates your monitors (HTTP, keyword, port, heartbeat) in one call. Idempotent — safe to re-run.

DELETE /api/account (or the Settings danger zone) removes every byte of your data. No email to support, no retention.

Scheduling a maintenance window now emails your status-page subscribers with scope, timing and your note — capped to prevent accidental spam.

Visitors can subscribe to any public status page (double opt-in) and get plain-text down/up emails with one-click unsubscribe.

Public status pages auto-refresh when a monitor changes state — no manual reloading during an incident.

A one-page plain-text quickstart so AI agents can sign up and create monitors with three curl commands.

New tcp monitor kind: connect checks for Postgres, Redis, SSH, game servers — every minute, with connect-latency stats and slow alerts.

Free phone push without installing a vendor app: point an alert channel at any ntfy topic (ntfy.sh or self-hosted).

New domain monitor kind: daily RDAP lookup, alert when registration is inside your warning window (default 30 days).

Public status pages show a per-day uptime strip for each monitor; uptime_90d added to the status-page JSON.

Raw checks (~3 days) and daily rollups (~90 days) export as CSV per monitor.

Custom accent color and logo on your status pages — free.

Every status page has a public 30-day incident feed for your feed reader.

Authed account-wide scrape at /api/metrics plus an unauthed page-scoped scrape at /s/{slug}/metrics — up/latency/uptime-ratio gauges per monitor.

The full API is described at /openapi.json (OpenAPI 3.0, validated).

POST /api/monitors/bulk creates up to 50 monitors in one call with per-item results and dedupe.

A status page can include all your monitors — current and future — with one flag.

SSRF-safe check fetches (every redirect hop re-validated), IP rate limits on auth endpoints, and recipient confirmation for third-party alert emails.

Match custom status codes ("2xx,301", "200-204") and alert when a keyword appears or goes missing from the body.

Set a per-monitor latency threshold; three consecutive slow checks fire a 🐢 alert, three fast ones send the ⚡ recovery.

Badges, monitor pages, status pages and JSON all report 7-day and 30-day uptime.

Optional Monday summary: uptime, response times and incidents for the week, with one-click unsubscribe.

Scheduled pauses suppress alerts and downtime; covered monitors show a blue maintenance state everywhere.

Outages auto-derive from your check history: 30-day list on status pages, GET /api/incidents, machine-readable /s/{slug}.json.

Embeddable SVG uptime badges (non-secret badge ids) and response-time sparklines on status pages.

Single-use, 1-hour email reset links; all sessions invalidated on reset.

Initial release: 1-minute HTTP checks, cron heartbeats, public status pages, email/Discord/Slack/webhook alerts, full JSON API — all free.