Multi-site security monitoring
Drop your sites into a watchlist. Every time you visit, SecurityWatch checks each one five ways: is it up, did the homepage get tampered with (that’s a page-hash thing), when does the TLS cert die, did a security header quietly vanish, and did WordPress jump a major version on you. Snapshots live in your browser, so when something shifts between two runs you get told in plain English. There’s an optional webhook too. Paste a URL and it fires a JSON alert the moment something breaks, which means you can pipe SecurityWatch straight into Slack or Discord or n8n (or honestly whatever you’ve cobbled together) with no backend at all.
Watchlist is stored in your browser only (localStorage). Clearing browser data removes it. No account required.
What SecurityWatch monitors and why it matters
Here’s the thing nobody tells you. Most of what wrecks a site in 2026 isn’t some glamorous zero-day. It’s the slow, boring stuff. A cert where auto-renew silently choked and now it expires next Tuesday. A security header that fell off during a theme update and nobody noticed. A CMS that upgraded itself a whole major version and broke a plugin in the process. Or a defacement that swapped your homepage for a crypto-jacking script, and it just sits there for three weeks because, well, who actually scrolls down to the marketing page? SecurityWatch is for the person running one site, or a handful, who wants to find out within hours instead of weeks that something visible from the outside has changed. The watchlist lives in your browser. You trigger the scans. The diffs between two visits show you what moved.
Five checks per site. Uptime is just an HTTP request that grabs the status code, the response time and where any redirects send you. Defacement detection hashes the homepage HTML after stripping out timestamps, nonces and ad markup, so a genuine content change trips it but the harmless churn doesn’t. TLS expiry reads the cert, who issued it, and how many days are left. Amber kicks in at 30 days. Red at 14. Security headers watches HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and yells when one that was there last time has gone missing. And WordPress version drift peeks at the generator meta and the ?ver= query hanging off your CSS / JS to catch a major-version jump that probably deserves a closer look.
How the monitoring workflow runs without a backend
- Add a site by pasting its URL, plus a label if you want one. The entry gets tucked into
localStorageunder the keypag-securitywatch-v1, right there in your browser. - Scan whenever you feel like it by hitting “Scan now”. The scan pings four public REST endpoints on the PeopleAreGeek server (
headers,ssl,status,seo-page) and stitches the results together. Nothing leaves for anywhere else. - Compare the fresh snapshot against the last one sitting in local storage. Whatever changed gets spelled out in plain English. Stuff like “TLS expiry dropped from 87 to 14 days” or “HSTS header is gone” or “homepage hash changed”.
- Optional webhook: drop in a URL (a Slack incoming webhook, a Discord webhook, an n8n catch endpoint, your own box, take your pick). When SecurityWatch spots a regression, it POSTs a little JSON over to that URL so the alert lands in your team chat or wherever your automation lives.
- Export the whole watchlist as JSON to back it up, or to haul it over to another browser. Import on the same page brings it back. No cloud account, and nothing locking you in.
Common use cases for SecurityWatch
- Small portfolio of client sites. Say you’re a freelancer babysitting ten WordPress builds for clients. Throw them all on the watchlist and run a one-click scan once a week, maybe Monday morning before standup.
- Migration safety net. Just moved a site to a new host or swapped CDNs? Run SecurityWatch right then, and again two days later. If a header or the TLS quietly regressed, you’ll see it.
- Defacement early warning. The page-hash check catches an unauthorised homepage edit minutes into the next scan. Way before you’d have stumbled onto it yourself.
- Certificate renewal sanity. Auto-renew is great until it isn’t. Certs still flub the install sometimes, a DNS challenge that won’t validate, an account that hit a rate limit. This is your last line of defense before visitors start seeing that ugly browser warning.
- Compliance evidence. Those exported JSON snapshots double as a halfway-decent audit trail when some lightweight framework wants proof you actually run periodic checks.
- Companion to SecuChecker. Once you’ve done the deep one-shot scan over in our SecuChecker tool, park the site here so the fixes you just applied don’t quietly un-apply themselves.
Limitations and privacy notes
Let’s be clear about what this is. SecurityWatch is a browser-side monitor, not a hosted service. It only scans when the tab’s open and you push the button. No cron sitting in the cloud, no email scheduler, no shared dashboard, no team logins. The catch is that the watchlist rides along with your browser. Private to you, sure, but wipe your browser data or hop to a different machine and it’s gone, unless you exported it first. If you genuinely need 24×7 hands-off coverage, bolt a CI cron onto the same endpoints, or lean on something like UptimeRobot or BetterStack for the pure uptime side. Honestly, for fast on-demand checks with zero signup, I think this is about the best free option going, though I’ll admit I’m biased.
The probes themselves are gentle. Plain HEAD or GET requests aimed at the public homepage of each site you’re watching. Every probe goes out from the PeopleAreGeek server, so that’s the IP the big CDNs will log, not yours. The watchlist, the snapshots, your webhook URL, the email you typed in, all of it stays in browser localStorage and never reaches PeopleAreGeek. And the optional webhook? It fires straight from your browser to the URL you set, so the recipient sees the JSON payload while PeopleAreGeek sees nothing.
Frequently asked questions
Does SecurityWatch run continuously in the background?
Nope. It only runs when you’ve got the page open and you hit “Scan all now”, or when you fire a per-site “Scan now”. Want it watching while no tab is open? You’ll need to hit the same endpoints from a cron job or a CI workflow instead.
Where is the watchlist stored?
In your browser’s localStorage, under the key pag-securitywatch-v1. It never gets shipped off to PeopleAreGeek or anywhere else. Planning to clear your browser data? Export to JSON first so you don’t lose it.
What is the defacement check exactly?
SecurityWatch grabs the homepage HTML, rips out inline scripts, head tags and the usual dynamic noise (timestamps, CSRF nonces, ad junk), then runs a SHA-256 over what’s left. If that hash differs from the last scan, it flags a possible defacement and leaves it to you to go eyeball the page. It can’t tell a hack from a legit redesign, so that final call is yours.
How do I wire the webhook to Slack or Discord?
First make an incoming webhook. In Slack that’s Workflow Builder or App Settings. In Discord it’s tucked under Edit Channel, then Integrations, then Webhooks. Grab the URL it gives you and paste it into the Alerts tab. SecurityWatch sends a JSON payload that both platforms understand right out of the box.
What counts as a security header regression?
It’s a header that showed up in your last snapshot but is now gone or sitting empty. Add a new header and SecurityWatch logs it as an improvement. Drop one and it’s a regression, weighted by how much that control mattered. Losing HSTS rates high. Losing Referrer-Policy, eh, low.
Will SecurityWatch trigger my WAF or my hosting provider?
Probably not. The probes are ordinary HTTP HEAD / GET requests hitting the public homepage at a slow trickle. To a WAF they look basically like a search-engine crawler stopping by. SecurityWatch never logs in, never POSTs a form, doesn’t fuzz parameters, and won’t wander past the homepage.
