What Managed WordPress Runs While You Sleep: Every Automated Layer Protecting Your Site

During our morning operations review, I pulled up the overnight summary from the monitoring stack. Twelve hours of automated activity: backup completed at 02:14, 1,127 intrusion attempts blocked across the platform, three SSL renewal checks run without triggering a renewal, one scheduled malware scan completed with no flags raised.

None of the site owners on our platform saw any of that. Most were asleep.

That is precisely the point.

Managed WordPress hosting gets described in terms of what it includes: backups, security, performance. What gets less attention is when those things run, what they look for, and what they do when they find something. This article covers that. Not the marketing summary, but the operational detail, presented in terms that matter to a business owner rather than a server administrator.

Every section below covers one automated layer. What it does. How often it runs. What happens when it detects something. And what it cannot do, because telling you it is complete when it is not would be irresponsible.

If you want the condensed version, the table below covers it. If you want to understand what is actually running behind your website, read the sections that follow.

Automated Layer	What It Monitors	When It Runs	Action Taken
Nightly backup	Full site: files and database	Every night	Backup stored; one-click restore available
Pre-update snapshot	Full site state before any change	Before each update or restore	Instant rollback available if something breaks
Intrusion prevention	Failed logins, suspicious request patterns	Continuously	IP banned at firewall level after threshold exceeded
Malware scanning	Files, database, core file integrity	Scheduled scans	Infected files flagged and isolated
SSL certificate monitoring	Certificate expiry window	Daily check	Auto-renewal triggered 30 days before expiry
Server hardening	Nginx config, PHP-FPM rules	Permanent configuration	Enforced on every request, no exceptions

The Nightly Backup

The backup runs every night. On Web60, that means a complete copy of your site (every file, every image, every database record) captured and stored automatically. You do not schedule it. You do not trigger it. It runs.

What a backup actually captures matters, because there is a common assumption that a backup is just your images and text. It is not. A WordPress site is two things: files (your theme, plugins, uploaded media) and a database (your pages, posts, settings, customer records, orders). Both need to be in the backup for it to be useful. If you have one without the other, restoring the site correctly is not possible.

The backup verification problem is real and under-discussed. Veeam's Data Trust and Resilience Report 2026, based on more than 900 senior IT and risk leaders worldwide, found that roughly nine in ten organisations expressed confidence in their recovery capability, but fewer than one in three ransomware victims actually recovered all their affected data when it came to it. That gap between confidence and reality almost always comes down to backup quality, verification, and what the backup actually covers. A backup that has never been tested may not restore correctly when you actually need it.

Web60's nightly backups are complemented by on-demand backups you can trigger manually before a significant change. If your site is compromised at 11pm on a Tuesday, the worst-case scenario is losing one day's activity, not everything you have ever published. That is the deal. Know the tradeoff.

For a full breakdown of how backup and security work together on WordPress, the Web60 WordPress security and backup guide covers it in comprehensive detail.

The Pre-Update Snapshot

This is a separate, distinct protection layer that most site owners do not know exists.

When a plugin updates (whether you push the update manually or it runs automatically) a complete snapshot of your current site state is taken before the update runs. Not after. Before.

Why does this matter? Most WordPress sites do not break because of hackers. They break at 2pm on a Thursday because a plugin update conflicted with something already installed, and nobody caught it until a customer could not complete checkout. The pre-update snapshot means that if an update breaks something, you do not troubleshoot. You rollback. One click. Done.

Pre-restore snapshots work the same way: before any restore operation runs, a snapshot of the current state is taken. So even the restore itself is protected. If a restore were to go wrong partway through, the safety copy is there.

This is the automation that pays for itself in avoided panic. The business owner does not need to know it ran. They only need it to be there when something goes wrong.

Intrusion Prevention: The Firewall That Never Clocks Off

fail2ban runs continuously. It monitors authentication logs and bans any IP address that exceeds a threshold of failed login attempts. Not rate-limits it. Not warns it. Bans it at the firewall, before it can send another request.

The scale of brute force attacks against WordPress is worth understanding. Wordfence, which tracks authentication patterns across its protection network, has reported blocking in the region of 65 million brute force attempts daily across its network alone. I would treat that as an order-of-magnitude figure rather than a precise count (measurement methodology varies, and Wordfence's network composition will affect the number), but the direction is clear. Automated credential attacks against WordPress are continuous and high-volume. A site without server-level protection is receiving these attempts constantly, whether the site owner is aware of it or not.

For a deeper look at how these attacks work and what they target, our breakdown of WordPress brute force attacks covers the anatomy of a typical campaign.

The critical technical point here is where the block happens. A plugin that limits login attempts blocks the user inside WordPress (the request has already consumed server resources to reach PHP and WordPress). fail2ban blocks at the network layer. Under a heavy, sustained attack, the difference between "blocked in WordPress" and "blocked at the firewall" is the difference between a site that stays responsive and a site that slows to a halt as each blocked request eats server resources.

The limitation: fail2ban triggers on failed attempts. A bot that has obtained a valid credential obtained from a breach elsewhere will not trigger the threshold. This is why two-factor authentication remains important alongside server-level protection, not as an alternative to it.

Malware Scanning: The Silent Audit

Scheduled malware scanning runs against your site's files and database. The scanner checks file integrity by comparing core WordPress files against known checksums, and looks for patterns consistent with known malware signatures: injected scripts, unexpected database rows, hidden redirect code.

Some context on the scale of the problem. In the first half of 2024, Sucuri's SiteCheck service scanned more than 53 million websites and detected over 680,000 infected sites. According to Sucuri's mid-year 2024 report, WordPress accounted for roughly 95% of those infections, though Sucuri's own methodology note is worth including here: that figure reflects the makeup of their scanning user base, which is heavily weighted toward WordPress, rather than being a precise measure of infection rates across the web. What it does indicate is where attackers concentrate their tools and techniques.

Most compromised sites are discovered by someone other than the site owner. A customer reports a strange redirect. Google Search Console flags a security warning. A browser throws a full-page block before a visitor can reach the site. Scheduled scanning means the detection can happen before any of that.

I will give you one honest operational admission. Earlier in our platform's history, before the current alerting architecture was in place, a malware flag on one site was miscategorised during a busy period and sat in a queue rather than triggering immediate escalation. The site had been compromised for just under two hours before a manual review caught it. We redesigned the alert classification system that same week. I still find that incident in our log occasionally. It is a useful reminder that automated detection is only as reliable as the human process that responds to it.

SSL Certificate Monitoring and Automatic Renewal

Let's Encrypt certificates are valid for 90 days. Certbot (the tool managing these certificates on the server) is configured to run a daily check and renew any certificate that is within 30 days of expiry. The renewal completes without interrupting the site, and Nginx reloads automatically to serve the new certificate. Nothing manual. Nothing to schedule.

Why does this matter in practice? An expired SSL certificate does not produce a quiet notice in the corner of a browser. It produces a full-page warning in red, telling the visitor the connection is not private and blocking them before they can proceed. For most business websites that is disruptive. For a Galway solicitor's practice, where every client-facing touchpoint needs to project absolute professional trust, a "connection not secure" warning is not a technical hiccup. It is a credibility event that takes time to recover from.

Automated SSL management means this scenario does not happen. The certificate renews before anyone outside the infrastructure layer would ever know it was approaching expiry.

One technical note worth understanding: Let's Encrypt emails the administrator address if an automated renewal fails. That is a backstop, not the primary process. The primary process is the automated renewal itself. The email is there because no automated system is infallible.

Server-Level Hardening: The Configuration That Does Not Change

This is not a scan that runs periodically. It is a configuration that is always in effect, applied to every request, without exception.

Nginx is configured with security headers, restricted access to sensitive WordPress paths, and request filtering at the server level. PHP-FPM runs with appropriate limits that prevent common exploit patterns. Direct PHP execution is blocked in upload directories, a common attack vector where malicious files are uploaded and then executed. XML-RPC, which has been used repeatedly to amplify brute force attacks by allowing hundreds of login attempts per request, is restricted at the server level rather than handled by a plugin that could be deactivated.

These settings are permanent. They are not re-applied on a schedule. They are not dependent on a plugin being active. They apply to every request that hits the server, including the ones that never reach WordPress at all.

The practical implication: your site is not secured once and left to drift. The hardening is in the infrastructure. It is there before you log in and after you log out.

The Sync Reality Check: What Automation Cannot Do

This section matters. Automated monitoring is strong. It is not complete.

Zero-day vulnerabilities: When a new vulnerability is discovered in a plugin, there is a window (sometimes hours, sometimes days) before a security signature exists. During that window, malware scanners have nothing to match against. Keeping plugins updated, and using a hosting platform that applies security patches promptly, is the mitigation.

Compromised credentials: fail2ban triggers on failed login attempts. A credential exposed in a breach elsewhere, then used correctly at the first attempt, will not trigger the threshold. Password hygiene and two-factor authentication are not optional extras. They fill a gap that server-level protection cannot.

Sophisticated obfuscation: Malware crafted specifically to avoid known signatures is harder to detect with signature-based scanning. Behavioural analysis helps, but there is no scanner with a 100% detection rate.

Human-introduced problems: A team member with legitimate credentials publishing incorrect content, deleting the wrong page, or introducing a conflict by installing an incompatible plugin. These are not security events. Automation does not manage access permissions or content review. Those remain operational decisions.

The timing gap in backups: Your nightly backup runs at a fixed time. If your site is compromised 22 hours after that backup completed, you lose 22 hours of work when you restore. That is the deal with nightly backups, and it is honest to say so. The alternative is no backup at all, which means losing everything. Know the tradeoff, manage accordingly.

The Strategic Concession

For large organisations running multiple WordPress installations with dedicated DevOps teams, custom deployment pipelines, and in-house security monitoring on their own SIEM systems, a self-managed infrastructure gives more granular control than any managed platform. That is a genuine use case where managed hosting is not the right fit. If you have a team with the expertise to manage it, the control is worth the overhead.

For the vast majority of local businesses running a website to serve customers, the question is not managed hosting versus a custom security architecture. It is managed hosting versus no structured security at all. That is a different comparison, with a different answer.

What This Means for Your Website

Web60's enterprise-grade Irish infrastructure handles all of this at the platform level. Not as optional modules you need to activate. Not as features you need to configure. As the baseline: what your site runs on from the day it goes live.

The automated stack runs every night, all day, every week. You are not managing it. You are not scheduling it. It runs because the infrastructure is built to run it.

What that means in practice: if your site is compromised, there is a recent clean backup to restore from. If a brute force campaign targets your login page, it is blocked at the firewall before WordPress is involved. If your SSL certificate approaches expiry, it renews itself. If a plugin update breaks something, the pre-update snapshot means you can rollback without rebuilding.

These are outcomes, not features. The technology is the means to get there.

Your website is not protected because someone turned on a plugin. It is protected because the infrastructure it runs on is configured that way. That distinction matters more than most business owners realise, usually until the evening they actually need it.

Frequently Asked Questions

What does managed WordPress hosting monitor automatically?

On a properly configured managed WordPress platform, automated monitoring covers nightly backups of files and database, pre-update and pre-restore snapshots, continuous intrusion prevention via fail2ban, scheduled malware scanning, daily SSL certificate expiry checks with automatic renewal, and permanent server-level hardening. These run without any action required from the site owner.

What is fail2ban and do I need to configure it on my WordPress site?

fail2ban is a server-level intrusion prevention tool that monitors authentication logs and automatically bans IP addresses that repeatedly fail login attempts. On Web60, fail2ban is configured and running at the server level. You do not install or configure anything. It blocks brute force attempts before they ever reach WordPress.

How does SSL certificate auto-renewal work on managed WordPress hosting?

Let's Encrypt certificates are valid for 90 days. Certbot runs a daily check and automatically renews any certificate within 30 days of expiry. The renewal applies without interrupting the site, and Nginx reloads automatically to serve the new certificate. No manual action is required.

What is the difference between a nightly backup and a pre-update snapshot?

A nightly backup is a scheduled complete copy of your site taken every night regardless of activity. A pre-update snapshot is a separate safety copy taken automatically immediately before a plugin update or restore operation runs. The nightly backup protects against data loss over time. The pre-update snapshot allows immediate rollback if an update breaks something, without waiting for the next nightly backup window.

What can automated WordPress monitoring not protect against?

Automated monitoring has real limits. Zero-day vulnerabilities may not be caught before a security signature exists. Compromised credentials used correctly may not trigger fail2ban thresholds. Malware specifically designed to avoid signature detection is harder to catch. Content errors or deliberate misuse by team members with legitimate access are not security events automation can prevent. These gaps are why password hygiene and two-factor authentication remain important alongside hosting-level protection.

How do I know if my nightly backup actually ran successfully?

On Web60, backup status is visible in the dashboard. You can check the timestamp of the last successful backup at any time. On-demand backups are also available if you want to create a manual checkpoint before a significant change. Pre-restore snapshots are taken automatically before any restore, so even the restore operation itself is protected.

Sources