In most dashboards, “24/7 monitoring” just means someone will notice if your homepage stops loading. It does not mean anyone is watching who logs in, what changes, or whether your protections quietly fail.
Website security monitoring should go beyond uptime to continuously check for unauthorized access, vulnerable software, unexpected code or content changes, and failed protections in your hosting and CDN stack.
If you haven’t already read it, our piece on related guidance on what to compare before treating uptime alerts as a website security strategy is the conceptual prerequisite: it separates “is the site up?” from “is the site safe?”. This article assumes you accept that distinction and want a concrete diagnostic: exactly what should be monitored, by whom, and what happens when something changes.
In support work, we often see the same pattern: marketing thinks hosting is “handling security”, IT assumes the agency has it covered, and the agency expects hosting to own anything below WordPress. Everyone can point to a green uptime graph. No one can show who is watching for real incidents.
This article walks through a layered model of monitoring you can check against your current setup in 10–15 minutes. By the end, you should be able to answer a hard question with confidence: what could go wrong tonight that your monitoring would not see?
Why “we monitor uptime 24/7” is not website security monitoring
Uptime monitoring answers one narrow question: did the server respond to a basic request? It’s closer to a power indicator light than a security system.
In practice, uptime tools:
- Ping a URL at intervals.
- Alert if the site stops responding or gets very slow.
- Maybe confirm the response contains a specific keyword.
Useful, yes. But consider a common scenario we’ve seen:
- A marketing director checks the hosting dashboard on Monday.
- Uptime is 100% for the weekend. No alerts.
- Yet search results now show spam pharma pages.
- Inside WordPress, new users with admin roles have appeared, and existing admins are locked out.
From the monitoring tool’s perspective, everything was fine: the compromised site still loaded quickly.
Security monitoring has a different job: prove that what’s running, who’s accessing it, and how it’s changing are all within the boundaries you intended. That’s the gap.
A simple test: what would your monitoring miss tonight?
To make this concrete, imagine it’s Friday afternoon.
You approve some minor content updates, a plugin auto-update is pending, and your IT team is rolling out a DNS change for another system. Everyone assumes the website is “covered.”
Ask yourself:
- If an attacker guesses or steals an admin password tonight, will anything alert you about that login or what they do next?
- If a plugin auto-update introduces a conflict and disables part of your site’s security, will anyone see that protection fail?
- If someone injects spam links into older posts, and human visitors rarely see them, what signal — if any — would surface that change?
- If DNS is misconfigured and points your domain to the wrong server, would your current monitoring notice before customers email on Monday?
If your only honest answer is “we’d see it if the site goes down,” you don’t have security monitoring. You have availability monitoring.
From here, we’ll map risks like these into six monitoring layers. Use them as a checklist, but more importantly as a conversation starter about ownership.
Layer 1 – Availability vs. integrity: what’s actually being watched
Most teams have availability checks. Far fewer have integrity checks.
Availability checks answer:
- Does the site respond with a 200 status?
- Is the page load time within a threshold?
Integrity checks answer:
- Is the content being served still the content we expect?
- Has the page structure changed in ways we didn’t approve?
- Are visitors being silently redirected somewhere else?
Concrete integrity signals you can monitor:
- Unexpected redirects from key pages (home, login, checkout, lead forms).
- Injected links or content blocks in high-traffic templates.
- Changes to robots.txt or meta tags that could deindex or hide pages.
- Modified core files or theme templates when no deployment was scheduled.
Diagnostic questions:
- Can anyone on your team point to a log or alert that would show if content or templates changed outside an approved window?
- Is anyone reviewing search console or similar tools for unexpected new URLs, spammy queries, or manual actions — and is that review part of a defined monitoring routine, not a once-a-quarter surprise?
If all you can show is a green uptime indicator, you’re only watching whether the lights are on, not whether someone changed the locks or repainted the store with a competitor’s logo.
Layer 2 – Access and admin abuse: who can do what, from where
Most incidents we see on business websites start with misused access, not exotic exploits.
Monitoring access is more than counting failed logins. You want a picture of who can do what, from where, and when that pattern changes.
Concrete access checks:
- Admin logins outside expected countries or IP ranges, especially for privileged roles.
- Multiple failed login attempts against a single account or from a small IP range.
- New administrator or editor accounts being created, especially outside working hours.
- Role changes that grant additional permissions unexpectedly.
- Dormant accounts that still have access but haven’t been used for months.
A realistic pattern: a small B2B firm rotates freelancers and agencies for site changes. Over time, a half-dozen admin accounts accumulate. One former contractor’s login is never removed. Months later, that account is abused. No alert fires, because nothing in the system is watching for new sessions from long-dormant admins.
Diagnostic questions:
- Can you list who currently has admin-level access, when their accounts were last used, and where they typically log in from?
- Would anyone be alerted if a highly privileged account logged in at 2 AM from a geography you never operate in?
- Does someone actively review access logs or summaries, or are they sitting in a dashboard no one opens?
If a risk can’t be seen in a log, alert, or report that someone reviews, you don’t have monitoring for it — you just have the possibility of forensics after something breaks.
Layer 3 – Software and dependency risk: what’s running your site
For WordPress and similar stacks, software is always shifting: core updates, plugin releases, theme changes, PHP versions, and dependency patches.
Too many teams equate “we run updates” with “we monitor software risk.” Those are different.
Monitoring here should answer:
- What versions of core, plugins, themes, and key dependencies are currently active?
- Which of those versions are known to be vulnerable or end-of-life?
- Did an update fail or partially apply, leaving the site in an inconsistent state?
Concrete checks:
- A current inventory of all active plugins and themes, with versions.
- Alerts or at least reports for critical security releases your site hasn’t adopted.
- Flags for abandoned extensions that haven’t been updated in a long time.
- Basic watch on PHP and database versions so you see deprecations or upcoming removals before a forced hosting upgrade.
This ties directly into what we call Maintenance Maturity — the shift from “we update when something breaks” to a proactive rhythm: know what’s running, know what’s changing, and know when you’re carrying avoidable risk.
Diagnostic questions:
- Who owns deciding when updates are applied: hosting, IT, an agency, or “whoever notices”? Is that ownership written down anywhere?
- If asked today, could someone show you a recent snapshot listing your key plugins and highlighting which ones are behind on security patches?
- When a major platform or plugin release ships, is there a planned review, or do you learn about it indirectly when a feature acts strangely?
Monitoring software risk is less about another shiny tool, more about whether you treat the site as a living system with a lifecycle you deliberately manage.
Layer 4 – Change and deployment signals: how edits become incidents
Even well-intentioned changes can create incidents: a rushed hotfix, a quick plugin install, a DNS tweak that was “just a small change.” Without monitoring, you only connect the dots days later.
A healthy change layer focuses on traceability:
- Who changed what?
- When did they change it?
- What else happened around the same time?
Useful monitoring signals:
- Deploy and release logs tied to environments (staging vs. production) and users.
- Audit trails for key configuration changes — security plugins, payment settings, redirects, caching rules.
- Content change history on critical pages: pricing, legal, forms, high-value landing pages.
- Simple “before and after” checks on key journeys (for example, does the quote form still submit successfully after a deployment?).
We have noticed during audits that many incidents labeled as “mysterious bugs” were introduced by quiet changes days earlier that nobody logged: a plugin switched, a WAF rule disabled for testing and never re-enabled, a redirect updated “temporarily.”
Diagnostic questions:
- When something breaks, can you quickly line up a recent list of deployments, plugin changes, and configuration edits?
- Are there any changes that can be made directly on production without creating a traceable log?
- Does your team have a habit of linking incidents back to specific changes, or do issues get closed with “no root cause found”?
Monitoring change is what turns troubleshooting from guesswork into a manageable investigation.
Layer 5 – Environment and edge: hosting, DNS, CDN, and WAF signals
Between your CMS and your visitors sits an entire layer of infrastructure: hosting, DNS, CDN, TLS certificates, and often a web application firewall (WAF).
This is where responsibility frequently fractures:
- Hosting claims they monitor the server.
- The CDN provider advertises global protection and caching.
- An IT team manages DNS as part of broader network duties.
- An agency handles application-level changes.
Individually, each may be watching something. Collectively, it’s easy for critical gaps to fall through.
Environment and edge monitoring should include:
- DNS record changes for your primary domains and subdomains, especially A, CNAME, and MX records.
- TLS/SSL certificate status — expirations, issuance from unexpected authorities, and mismatches.
- WAF events and rule status: spikes in blocked requests, disabled rules, and exceptions added for “quick fixes.”
- Rate limiting and traffic anomalies: sudden floods of requests to login pages, search endpoints, or form handlers.
- Origin health from the CDN’s point of view — a subtle but real signal when the application starts failing intermittently.
Diagnostic questions:
- If someone accidentally or maliciously changes your DNS tonight, who gets notified? Is that person close enough to the website to understand the impact?
- If your SSL certificate is about to expire, does anyone see an alert and own renewing it before browsers start warning users away?
- Is anyone regularly reviewing WAF or edge logs, or are they treated as “expert-only” data you never open unless support asks for it?
For supporting context before making that decision, Website Support articles explains the adjacent issue in more detail.
Uptime checks alone rarely notice these issues until they surface as a full outage, and sometimes not even then if a misconfiguration still returns a 200 status.
Making this diagnostic: scoring your current monitoring coverage
To keep this practical, turn the five layers into a quick scoring exercise. For each layer, choose the statement that best matches your situation:
Layer A – Availability & Integrity
- 3 – Mature: We have uptime checks and specific integrity signals (content changes, redirects, core file modifications) tied to alerts someone owns.
- 2 – Partial: We have uptime checks and occasionally review other signals manually, but it’s not systematic.
- 1 – Fragile: We only have basic uptime or rely on “if customers complain, we’ll know.”
Layer B – Access & Admin Abuse
- 3 – Mature: We monitor admin logins, role changes, and failed attempts, and someone reviews summaries or alerts.
- 2 – Partial: Logs exist, but nobody regularly reviews patterns or dormant high-privilege accounts.
- 1 – Fragile: We rely solely on passwords and maybe 2FA; access logs are essentially ignored.
Layer C – Software & Dependencies
- 3 – Mature: We maintain an inventory, track vulnerable versions, and apply updates on a deliberate schedule.
- 2 – Partial: Updates happen (often automated) but with little visibility into what’s running or what’s at risk.
- 1 – Fragile: Updates are ad hoc and mostly triggered by breakages or prompts.
Layer D – Change & Deployment
- 3 – Mature: All production changes are logged, tied to people and timestamps, and used during incident review.
- 2 – Partial: Some changes are logged, but hotfixes and “quick edits” often bypass the process.
- 1 – Fragile: Anyone can change almost anything in production with no reliable trail.
Layer E – Environment & Edge
- 3 – Mature: DNS, TLS, WAF, and CDN events are monitored, with clear ownership on who responds.
- 2 – Partial: Vendors send emails or notifications, but nobody treats them as part of a coordinated monitoring routine.
- 1 – Fragile: We only touch these layers reactively when something breaks.
Now look at your scores:
- Mostly 3s: You’re operating with higher Maintenance Maturity. The key risk is drift over time and people changing roles — you’ll want to keep ownership explicit.
- A mix of 2s and 3s: You have foundations, but blind spots remain. Incidents here are often “known unknowns” that everyone assumes someone else is watching.
- Two or more 1s: You don’t yet have security monitoring; you have pockets of visibility. Incidents can simmer for weeks because there’s no systematic way to see them.
Remember: more tools doesn’t automatically move you up this scale. Clear ownership and regular review do.
When gaps in monitoring become governance problems, not just IT tasks
At first, monitoring gaps look like technical issues:
- “We didn’t have an alert for that.”
- “The log wasn’t turned on.”
- “The plugin didn’t catch it.”
Over time, they point to something deeper: Governance Collapse — the point where freedom to publish, add tools, and change providers isn’t matched with clear standards or ownership, and the site’s risk profile drifts out of anyone’s control.
We often see versions of this:
- Marketing can install plugins and make major layout changes.
- IT controls DNS and certificates but doesn’t see day-to-day site activity.
- Hosting owns server-level alerts but not what’s happening inside WordPress.
- An agency handles campaigns and front-end work but isn’t responsible for access or edge configuration.
Because each group touches a different layer, each assumes another group is handling monitoring. The phrase “we have monitoring” becomes a comfort blanket with no specifics behind it.
That’s why we push a simple, sometimes uncomfortable discipline: move from “we have monitoring” as a vague comfort phrase to a concrete answer about which signals are watched, by whom, and what happens when they change.
This is an operating-model decision, not a tooling choice. Until you decide who owns which signals and how they’ll respond, buying more plugins or subscribing to another security product mostly adds noise.
Next steps if you discover two or more blind layers
If your scoring surfaced 1s in two or more layers, you don’t just have blind spots — you have a pattern that will repeat:
- Incidents won’t be seen quickly.
- Fixes will be rushed and poorly documented.
- Those rushed fixes will introduce new, harder-to-detect risks.
- Over time, stakeholders will lose confidence in the site as a reliable asset.
Here’s how to turn that around without assuming a full-time security engineer.
-
Name ownership for each layer. Even in a small team, decide: who owns availability & integrity, who owns access, who owns software, who owns change, who owns environment & edge. One person or partner can own multiple layers, but no layer should be “shared by everyone.”
-
Write down the minimum signals per layer. Use the concrete examples above and ask, “Which of these can we realistically monitor this quarter?” Avoid perfection; aim for a visible, reviewable set of signals.
-
Schedule real reviews, not just alerts. Alerts matter, but so do weekly or monthly reviews where someone scans summaries, closes false positives, and adjusts thresholds. More alerts with no review is a hidden failure mode; it trains people to ignore everything.
-
Align monitoring with Maintenance Maturity. Treat this as part of moving from reactive fixes to intentional stewardship of the site’s risk and stability, not as an isolated “security project.”
If, after walking through this, you can see that your current vendors provide pieces of the puzzle but no one is accountable for the whole picture, it may be time to bring in a partner whose job is to design and run that operating model with you.
For organizations that want a cohesive approach rather than another disconnected tool, our Website Security & Monitoring work focuses on defining which signals matter for your site, mapping who owns them, and putting review rhythms in place so incidents are seen and handled before they become public problems.
If you’d like to talk through your scores or compare your current stack against a layered monitoring model, you can start a focused conversation through a short message describing your current monitoring setup and responsibilities — we’ll respond with where we see the largest blind spots and what a pragmatic path forward could look like.
And if you want to explore how this fits into broader ongoing care for your site — not just security — our Website Support articles offer more context on maintenance, governance, and the operational habits that keep a serious website stable over time.
Before the next website change, document and approve the ownership decision this article has outlined.