v0.16.0 — Site monitoring: fingerprints, a doctor, and a Redis sentinel

We've engineered a monitoring solution that's state-of-the-art for SpinupWP fleets — per dollar and per gram of installed weight. Zero agents, zero SaaS, nothing installed on your sites: every check runs from Uptime Kuma and a one-line cron you already had. The parts are commodity; the composition is the invention — each check deliberately watches either through the page cache (is the right thing being served?) or around it (is the machinery behind it alive?).

Highlights

• The front-page check (f). The page cache can serve the wrong page while HTTP stays 200 — two production incidents showed a search-results template where the home page belonged, and every up/down monitor stayed green. Instead of a hand-picked headline keyword (which breaks the day someone edits the copy), Spinup reads your healthy front page, derives a template-identity fingerprint from what WordPress itself stamps into the markup (class="home, page-id-N, …), proves it discriminates against a throwaway search render, and registers the Kuma keyword monitor for you — at your chosen window (5m–1h; the check is served straight from the page cache, so it costs the site nothing). Red shows as WRONG PAGE SERVED in Details. Re-running f recalibrates the same monitor in place — history survives a redesign.
• The site doctor (d). Read-only, zero setup, works without Kuma. It fetches your page twice — once normally, once with the cache-bypass cookie — and lets the server's own fastcgi-cache: HIT/BYPASS headers prove which layer answered each request, then compares template identity between the two: "the cache is lying" becomes a demonstrated fact with a copyable runbook, not a hunch. It also knocks on the wp-admin door (the login page — never cached; Bedrock's relocated /wp/ login handled; protected logins report "can't judge", never a false alarm).
• The partial-outage verdict. The nastiest failure shape we found — verified live: with SpinupWP's default object-cache drop-in, a dead Redis is fatal (HTTP 500) for every request that misses the page cache. Cached pages keep serving 200, so visitors look fine while wp-admin, logged-in users and everything dynamic is broken — and page-watching monitors sleep through all of it. The doctor now diagnoses it explicitly (a PHP fatal in a plugin/theme produces the same signature and is caught the same way, including admin-only fatals via the door probe).
• The Redis sentinel. One per server, riding the existing heartbeat cron: redis-cli ping every minute, pushed to its own {server} redis monitor that alerts independently. Registered by a/R on a vanity site — after probing that Redis actually answers on that box — and its token rotates with r like every other secret. Given the fatal-on-cache-miss behavior above, this one-minute sentinel is the primary detector for a real partial outage.
• Alert wiring (n). Spinup detects the notification providers configured in your Kuma — by name, not assumed — and shows whether each is attached to this site's monitors (✓ all / ◐ some / ○ none); ⏎ toggles a provider across all of the site's checks at once, editing monitors in place. Creating the provider (bot tokens etc.) stays in Kuma; wiring it to sites now lives in Spinup.
• M everywhere. The site-monitoring overlay opens with capital M from Servers, Stacks and Search alike (Servers keeps lowercase m too) — one muscle-memory key across the app.

Fixed

• A finished operation's message no longer hides the monitoring overlay's action menu for the rest of the session — results show above the menu, and the overlay always reopens fresh.
• The ?/i help overlays could deadlock open if triggered in the beat before a view's text input grabbed focus; dismissal now runs first.

Notes

• Every claim above was verified against live infrastructure before shipping: body-class fingerprints on the incident-prone production sites, fastcgi-cache headers on two servers, the drop-in's exception handling read from source, and a full stop-Redis/watch-it-alert/restart cycle on the test box.
• Honest boundary: this is not APM-grade observability — it's the meaningful subset for this stack, at effectively zero cost and zero installed weight. Checks that can't prove something say "can't judge" instead of guessing.
• A per-site health endpoint (deeper internals: eviction thrash, graceful-mode inventory, DB health) is designed and deliberately parked for a future release.

Update: press u in ? Help, or git pull in your checkout. No new dependencies.

Full changelog: v0.15.0...v0.16.0

🤖 Generated with Claude Code