How to monitor a WordPress site, and how often to check each part

What is WordPress site monitoring?

WordPress site monitoring, or WordPress website monitoring, is the ongoing check that a site is up, secure, fast, backed up and still doing its job. It differs from a one-off audit in two ways: it runs on a schedule without anyone remembering to do it, and it tells you when a check fails instead of waiting for you to look.

Good monitoring looks at a site from two sides. From outside, it sees what visitors see: is the site answering, is the certificate valid, how fast does the page load. From inside, it sees what only WordPress knows: which plugins are installed and whether they have known holes, who signed in, whether last night's backup finished. You need both, because a site can look fine from outside while something is wrong inside, and the other way round.

What WordPress monitors on its own

WordPress includes a few monitoring tools. They help, but they all have the same blind spot.

• Site Health (since 5.2). Under Tools > Site Health, the Status tab lists critical issues and recommended improvements, such as an outdated PHP version, background updates that do not work or a failing loopback request. The Info tab lists your WordPress version, server, database, plugins and file permissions. Since 5.4, a dashboard widget shows the result and a weekly background check runs on its own. Site Health does not email anyone.
• Recovery mode (since 5.2). When a plugin or theme causes a fatal error, visitors see a "technical difficulties" message and WordPress emails the admin address a link that opens wp-admin with the faulty code paused. The link expires after a day by default.
• The debug log. With WP_DEBUG and WP_DEBUG_LOG turned on, PHP errors are written to wp-content/debug.log. WordPress's own documentation advises against running debug tools on live sites, so use it while you investigate, then turn it off.

The blind spot: all of this runs inside the site. If the server is down, the database is unreachable or the domain has lapsed, WordPress cannot send an alert. Its scheduler, WP-Cron, also only runs when someone visits a page, so on a quiet site scheduled checks can run late. That is why monitoring has to include checks from outside.

What to monitor on a WordPress site, check by check

1. Uptime and response time

Check that the site answers every one to five minutes, and alert when it does not. Check from more than one location, because a network problem between one monitor and your host looks exactly like an outage. Response time matters too: a site that takes eight seconds to answer is failing visitors before it fails completely. Our guide on how to monitor WordPress uptime covers intervals, locations and setup in detail.

2. SSL certificates

Certificate monitoring used to be a once-a-year concern. Not any more. The CA/Browser Forum, which sets the rules for public certificates, passed ballot SC-081v3 in April 2025. Certificates issued since 15 March 2026 last at most 200 days; from 15 March 2027 the limit drops to 100 days, and from 15 March 2029 to 47 days. Automatic renewal handles most of this, but every renewal is another chance for something to fail quietly. Check expiry daily and alert at least 14 days ahead.

3. Domain expiry

A lapsed domain takes the website and its email down together. Under ICANN's rules, registrars must send reminders about a month and a week before expiry, and after expiry they disrupt the domain's DNS before deleting it. For most generic domains there is then a 30-day redemption period, during which you can usually get the domain back for a fee. Reminders go to the registrant's email address, which on client sites is often an old one. Monitor expiry dates yourself.

4. Security: vulnerabilities, malware and sign-ins

The numbers explain why this check is daily. Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42 percent more than in 2024. 91 percent were in plugins, 9 percent in themes, and only 6 were in WordPress core. Almost half had no fix from the developer in time for public disclosure, and for heavily exploited vulnerabilities the median time to the first attack was five hours.

So the useful security checks are: every installed plugin, theme and WordPress version matched against a vulnerability database daily; malware and changed core or plugin files; and sign-ins, including password guessing and new administrator accounts. Free security plugins help, with a catch worth knowing: Wordfence's free version gets new firewall rules and malware signatures 30 days after premium users. Also verify the site in Google Search Console, which emails verified owners when Google suspects the site has been hacked.

5. Updates waiting

Pending updates are the most common way into a WordPress site, so review them at least weekly and apply security releases quickly. If you let WordPress update on its own, read our guide to WordPress automatic updates for what it covers and what it misses.

6. Backups and restore tests

Check daily that the last backup finished and was stored away from the server. Once a month, restore a backup somewhere safe to prove it works. A backup that has never been restored is a hope, not a plan. Our WordPress backup guide covers what to include and how often.

7. Performance and Core Web Vitals

Google's Core Web Vitals measure loading (Largest Contentful Paint), responsiveness (Interaction to Next Paint, which replaced First Input Delay in March 2024) and visual stability (Cumulative Layout Shift). A page is "good" when LCP is within 2.5 seconds, INP is 200 milliseconds or less and CLS is 0.1 or less, measured at the 75th percentile of real visits. Real-visitor data comes from the Chrome UX Report, shown in PageSpeed Insights and Search Console; lab tools such as Lighthouse are useful for testing changes but cannot measure INP. Check weekly and after every round of updates, because a plugin update is the usual cause of a sudden slowdown. When a page fails, our guide on how to improve Core Web Vitals on WordPress covers the fixes.

8. Forms and checkout

A broken contact form still says "thank you". The failure is silent: the email never arrives and nobody notices until a client asks why enquiries stopped. Send a test submission weekly, or watch the enquiries themselves and treat a quiet week on a busy site as a warning. Our post on a WordPress contact form that has quietly stopped lists the usual causes. On WooCommerce, run a test order through checkout after updates.

9. Users, roles and Site Health

Once a month, look for administrator accounts you do not recognize, people who have left and accounts nobody has used in months. Our guide to WordPress user roles explains which role each person should have, and an audit log shows what they did with it. Open Site Health at the same time and fix any critical issues.

A WordPress monitoring schedule you can copy

Here is the whole routine in one table, with a free way to start on each check.

To set it up on a single site, work through these steps in order:

1. Add uptime monitoring. Check the home page and one key page every few minutes, from more than one location, with alerts by email.
2. Watch SSL and domain expiry. Turn on certificate and domain expiry checks, with an alert at least 14 days ahead.
3. Set up security checks. Use a security plugin or service that checks for known vulnerabilities daily and scans for malware and changed files.
4. Verify the site in Google Search Console. Google then emails you about hacked content, manual actions and indexing problems.
5. Make backups report back. Turn on failure emails in your backup tool and schedule a monthly test restore.
6. Record a speed baseline. Note the Core Web Vitals for your key pages and test again after every round of updates.
7. Send alerts to a person. Point every alert at an inbox someone reads, and review the quiet checks once a week.

WordPress monitoring tools

There is no single free WordPress monitoring tool that covers everything above. Most people combine a few:

On one site, that combination works. On ten, it means forty or fifty dashboards, logins and email streams, and the alert that mattered lands between twenty that did not.

Alerts that people trust

Monitoring only works if someone acts on the alerts. The fastest way to break that is noise: after a week of false alarms, people stop reading them. Three rules keep alerts worth reading:

• Confirm before alerting. An outage should be confirmed from more than one location before anyone is told. Jetpack Monitor, for example, rechecks a suspected outage from three servers in different places and only alerts if all three fail.
• Separate notes from alarms. A plugin updating its own files is a note. A new administrator at 3 a.m. is an alarm. Only alarms should interrupt someone.
• Send alerts to a person, not a shared inbox nobody owns. WordPress sends its own emails to the site's admin address. Make sure that address reaches someone who reads it.

Monitoring multiple WordPress sites from one dashboard

If you look after more than a handful of sites, the checks above stop fitting into anyone's week. The answer is to monitor multiple WordPress sites from one dashboard, where every site is checked the same way and only problems reach you. (Disclosure: WPCentrify is our product.)

We run WPCentrify on our own sites. The account we use day to day manages 18 WordPress sites with automated checks around the clock. On 10 October 2026, the morning we finished this guide, its dashboard showed 11 updates waiting for review across those sites. That is the kind of number that is easy to miss when each site has its own wp-admin, and obvious when they share one screen.

WPCentrify is a WordPress website management platform. For monitoring, it covers:

Sources

• Site Health Screen, WordPress.org documentation, and Fatal error recovery mode in 5.2, Make WordPress Core
• Debugging in WordPress and Cron, WordPress developer documentation
• Ballot SC-081v3, CA/Browser Forum
• Expired Registration Recovery Policy, ICANN
• State of WordPress Security in 2026, Patchstack
• Web Vitals and INP becomes a Core Web Vital, web.dev
• Jetpack Monitor, Jetpack support, and Wordfence on WordPress.org
• Security issues report, Google Search Console Help

All sources checked on 10 October 2026.