WordPress monitoring
“We monitor your website” is a sentence, not a specification. This page is the specification: every check SiteVigilante runs against a WordPress website you manage, how often it runs, what it touches, and how far back you can read the answer.
One website, one day, every check
Ordered by how often it happens. Nothing here needs anybody signed in, and nothing here is a button somebody has to remember to press.
Is the website answering visitors?
One ordinary GET of the public page, from outside, through the same classifier the rest of the product uses. Not a ping and not a port check — what a visitor would get.
The pages you said actually matter
Nominate the pages and journeys a client would notice within the hour — a shop's checkout, a booking form, a members' area — and they are checked more closely and more often than the homepage.
Status from the website itself
The connected plugin reports its versions, its components and its own health, so a connection that has broken surfaces on its own rather than the next time somebody looks.
The published advisory feed
Refreshed hourly and matched against the versions actually installed across your estate, rather than against a list of plugin names. A feed that stops refreshing becomes an honest “cannot tell” rather than a silent “clean”.
Core file integrity
WordPress core files compared against what that release is supposed to contain, so a modified core file is found the next morning rather than the next quarter.
File integrity, indicators and correlation
The heaviest thing this product does to somebody's host, so it runs when their visitors are fewest and never overlaps the update run — files changing while they are being read would produce a reading assembled from two different websites.
Can the database still be written to?
The check that exists because of a real failure: a hosting quota lock that removed
INSERT and UPDATE while leaving SELECT in place.
Logins, uploads and orders all failed while every read-only check reported the website
as fine.
TLS certificate expiry
One handshake per website per day. A certificate that lapses takes the website out for everyone at once, and it always lapses on a date somebody could have known.
Domain name expiry
The published expiry date, read from the registry. The one failure that takes the website and the email at the same moment.
How a search engine sees it
A noindex left on after a rebuild is invisible from the front end and
costs a client their traffic for however long nobody notices. Read from the robots meta
tag, the response header and robots.txt — all three, because a website blocked by
only one of them looks clean to anything that reads only another.
Mail path and deliverability
The DNS records that decide whether a client's password resets and order confirmations land in an inbox or in spam, and what the website itself says about mail it has failed to send. Read-only: no record is ever changed by this product.
Cloaking, and broken links
Whether the website shows a search engine something different from a visitor, and a bounded crawl of its own pages followed by one status check per link. Both are heavy on somebody else's server, so they run weekly and on different days.
Two things are deliberately not on this timetable, because they are not scheduled: the full security scan and the PageSpeed test. Both run when you ask for them, and both of those pages say so rather than letting this one imply otherwise.
Up, down, and the answer most tools do not have
A monitor that only knows two states has to guess, and it guesses in whichever direction makes its dashboard look calmer.
The website answered, and what came back was the website. A success code alone is not enough to earn this.
Nothing answered, or what answered was not your website: a hosting suspension page, a
fatal error, or a body too small to be a page. Several of those arrive with a
200.
Something got in the way and we cannot honestly say. A bot-protection challenge, an
ambiguous 503, a response too large to read. Never counted as
up.
The third state is the one that matters commercially. A website behind bot protection answers a monitoring service with a challenge page and answers a human perfectly; calling that “down” wakes you at 3 a.m. for nothing, and calling it “up” means you find out about the real outage from your client.
So it is recorded as neither, and it is visible as neither. An observation this product could not make is never quietly filled in with the answer that reads better.
Refused as “up”
- A hosting suspension or parking page served with a success code.
- A PHP fatal error in the body, however the status line reads.
- A body too small to be a page.
- A bot-protection challenge — unknown, not down.
Thirty days, and the page says thirty days
Observations are kept for 30 days and pruned by the job that writes them. You can read the last 24 hours, the last 7 days or the last 30 — and there is deliberately no longer window, because a longer one could only describe itself as empty at the far end and invite you to draw a conclusion from a gap this product created on purpose.
There is a second figure beside the percentage, and it is the one that stops the first from lying: how much of the window was actually watched. A website connected three days ago can report 100% uptime with complete coverage, and a reader would take that for a month without an outage. The readings taken are stated against the readings the cadence would have produced, and a window the record does not cover says so before the figure does.
Uptime history
- Observation interval
- 4 minutes
- Retention
- 30 days
- Windows
- 24h · 7d · 30d
- States recorded
- up · down · unknown
- Window coverage
- always shown
And when it tells you
Monitoring nobody hears about is a log file.
One message, not a storm
Alerts are buffered and sent as a single combined message rather than one email per check per website. An estate of sixty websites having a bad morning should produce something you can read, not four hundred notifications you learn to filter.
You choose which kinds
Offline websites, failed updates, rollbacks, deactivations, critical security findings, a security summary, performance, runtime fatals, and a report being ready — each is a separate switch on your account rather than one blunt on-and-off.
A condition has to survive a second look
Reachability escalation corroborates against the website and requires the condition to still be there on a later check before anybody is emailed. That design exists because the alternative was measured and it was noise.
A daily summary either way
One digest covering the estate, so the mornings when nothing needed you still tell you that nothing needed you. Reaching the end of a quiet week and knowing it was genuinely quiet is most of what this product is for.
Connect one website and read tomorrow morning
The trial runs 14 days and starts without a card. Connect a website you already look after, leave it overnight, and read what a full cycle of this timetable found.
Read next
Security monitoring
Which of these checks are security checks, what a finding carries, and the things this product deliberately will not do.
Performance monitoring
The one measurement that is not on the timetable above, why it is not, and what it returns when you ask for it.
Client reporting
How the observations above become a document your client reads — including what happens to a month nobody was watching.
WordPress management for agencies
The estate view these checks feed: clients, component inventory, team access and what it costs.