You run care plans for a wall of WordPress sites. StatusKit watches every one from the outside — the way a visitor reaches it — and tells you the moment a site goes down, slows to a crawl, or a cert or domain is about to lapse. No plugin to install, nothing to keep updated on forty sites.
// one board for the whole roster — status, response time, and the next cert or domain to expire, watched from the outside. No agent, no plugin, nothing to maintain on the sites themselves.
Every WordPress management tool wants a plugin on the site and a connection to keep alive. That's another thing to update across forty installs, another thing that breaks when a host or theme changes, another attack surface. StatusKit takes the opposite approach: it watches each site the way its visitors do — from the outside, over HTTP — so there is nothing to install and nothing to keep running on the sites themselves. You add a client by its URL, and it's under watch. That's also the honest boundary: StatusKit doesn't log in, update, back up, or scan your sites. It watches, and it tells you the instant something's wrong. One job, done well.
A care plan is a promise that someone is watching. When you look after ten, forty, a hundred WordPress sites, that watching can't live in your head. StatusKit puts the whole roster on one board — what's up, what's slow, and every certificate and domain sorted by soonest to lapse — so the promise is automated instead of remembered. Here's what it watches on each site:
Each site is fetched on a schedule. The moment one goes down — or answers with a 5xx error — you get an email and a webhook, and again the moment it recovers. You hear it before the client does.
Every HTTP check records how long the site took to answer and plots the trend, so a site that's technically up but crawling — a bloated plugin, a struggling host — is visible before anyone files a ticket.
The HTTPS certificate on each site is watched, with staged alerts at 30, 14, 7 and 1 days. No client ever opens their own site to a browser padlock warning because a cert quietly lapsed.
The domain registration is watched on the same 30/14/7/1 ladder — the failure that takes a whole site offline overnight and is the easiest of all to miss across a big roster.
Every cert and domain across the entire client roster in a single view, sorted by soonest to lapse. Renewals stop sneaking up on you the week they're due.
Turn on a branded status page for any client — their name, their colour — so they can see uptime and incidents on a URL instead of emailing you to ask if the site is down.
You already know your clients' URLs; adding them is the whole setup. Add a site in the console and it's under watch on the next probe — up/down, response time, cert and domain. Prefer to keep the roster in version control? Define every client in a monitors.json and apply it from CI, so onboarding a new client is one line in a file. And when a client asks "is it up?", hand them a branded status page instead of an answer — their name, their colour, the uptime you're keeping. Cert and domain expiry get their own deep-dive over on SSL & domain monitoring.
No — and that's the point. StatusKit watches each site from the outside, exactly the way a visitor's browser reaches it. There's nothing to install on the site, nothing to keep updated across a roster of forty, and nothing that can break when a client's host or theme changes. You add a site by its URL and it's under watch.
No. StatusKit is a monitor, not a management plugin — it doesn't log in, update WordPress, take backups, or scan for malware. It does one job: it watches whether each site is up, fast, and not about to lose its cert or domain, and it tells you the instant something's wrong. That focus is why there's nothing to maintain on the sites themselves.
Yes — that's what it's built for. Put your whole roster under monitoring and see it as one board: what's up, what's slow, and every cert and domain sorted by soonest to expire. You can even keep the fleet in a monitors.json in version control and apply it from CI, so onboarding a new client is one line in a file.
Each site is probed on a schedule; when one goes down or returns a server error, StatusKit emails you and fires a webhook (into Slack, a PagerDuty, or your own endpoint) — then does it again when the site recovers. You find out from the alert, not from the client's message the next morning.
Yes. Every check records the response time and plots a trend, so a site that still returns a page but has slowed to a crawl — the classic symptom of plugin bloat or an overloaded host — shows up on the graph and on the client's status page before it turns into a support ticket.
A care plan is a promise that someone is watching. This is the watching — automated, honest, and cheap enough to fold into every plan. Start on the free checker to test one client's site right now (uptime, SSL and domain, no signup), then put the roster under monitoring and hand each client a status page.
Start free — check any client's WordPress site right now for uptime, SSL and domain, no signup. When you're ready, put the roster under monitoring and give each client a status page.