Website maintenance automation: what to automate in updates, backups and uptime monitoring, and how to set RPO/RTO (2026)

Website maintenance slides down the list the longer nothing goes wrong. Update notices pile up, backups become "probably running", and certificate expiry is handled whenever someone notices. Then, on the day something breaks, you find out whether you can restore.

This article sets out how far to automate five parts of website maintenance, and what to leave to people: CMS, plugin and PHP updates, backups and restore tests, uptime monitoring, SSL certificate and domain expiry, and incident communication. What to automate overall is in "Automating website operations starts with an inventory", pre-publish checks in "Automated blog publishing needs a quality gate", and analytics in "Search Console and GA4 monitoring automation". Here the focus is keeping the site running, unbroken and restorable.

Main sources for this article: the official WordPress.org documentation (automatic updates, backups, requirements), the PHP supported versions table, announcements from Let's Encrypt and the CA/Browser Forum, backup guidance from CISA (US), the NCSC (Netherlands) and IPA (Japan), and Google Search Central on server errors, all checked on 24 October 2026.

1. What is changing: a year that rewrote the assumptions

Between 2025 and 2029, a series of changes alters how much effort maintenance takes.

Certificate lifetimes shrink in stages to 47 days

The CA/Browser Forum, the industry body of browsers and certificate authorities, passed ballot SC-081v3 on 11 April 2025. The maximum lifetime of server certificates becomes 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, down from 398 days. Japan's JPRS has announced service changes on the same schedule.

Let's Encrypt, which issues free certificates, moves faster: from today's 90 days to 64 days on 10 February 2027 and 45 days on 16 February 2028. The period for reusing domain validation shrinks from 30 days to 10 days and finally to 7 hours.

Notifications have changed too. Let's Encrypt stopped sending expiry reminder emails on 4 June 2025, citing widespread automated renewal, privacy and cost. Watching expiry dates is now the site owner's job.

PHP 8.2 security support ends on 31 December 2026

According to the official PHP supported versions table, security fixes end on 31 December 2026 for 8.2, 31 December 2027 for 8.3, 31 December 2028 for 8.4 and 31 December 2029 for 8.5. Each branch gets two years of active support from release, then two years of security fixes only. Emergency patching is covered in "PHP2Shell and the Dutch government warning"; here the point is upgrading on a plan.

WordPress is on 7.x, with a rollback for failed auto-updates

The WordPress releases page lists 7.1.3 and 7.0.7, both released on 6 October 2026. The requirements page recommends PHP 8.3 or higher, while 7.1 runs on PHP 7.4 at minimum. Since WordPress 6.6, when a plugin auto-update causes a PHP fatal error, the previous version is restored automatically. That makes automatic updates easier to recommend, but there are failures it does not catch (section 3).

A once-a-year manual renewal becomes roughly four a year after March 2027 and eight after March 2029. Nobody can reliably remember that cadence, so automation and monitoring become prerequisites.

2. What maintenance automation means: four areas, and where other workflows begin

Automating maintenance means building, as a pair, the task the machine does and the mechanism that tells a person when it fails. With only one half, failures pile up silently. Each of the four areas protects something different.

Judgement stays with people in every area. Automation removes the effort of checking, copying and notifying, and underpins every other workflow.

3. Deciding what can update automatically

WordPress lets you choose, per type, whether updates are automatic. Start by checking what is automatic today.

The four types of WordPress automatic updates

According to the official WordPress documentation, there are four types of automatic update: core, plugins, themes and translations. The mechanism arrived in 3.7, and the screens for enabling plugin and theme auto-updates one by one arrived in 5.5.

Sites installed before 5.6 may still have major updates set to manual. In wp-config.php, WP_AUTO_UPDATE_CORE accepts true (all), false (none) or 'minor' (minor only), and overrides the setting on the Updates screen. Setting AUTOMATIC_UPDATER_DISABLED to true stops all automatic updates, which the official documentation strongly discourages.

Plugin and theme auto-updates run twice a day by default, and administrators receive the results by email. They rely on WordPress's internal scheduler (WP-Cron), which does not run in every environment. Check Tools → Site Health for errors.

The criteria: impact of a failure and ease of rollback

Decide which plugins update automatically on two axes: the impact if it breaks and how easy it is to roll back. Low impact and easy rollback means automatic; high impact or hard rollback means check before applying.

Payment and membership plugins sometimes change the database during an update, and restoring the files does not restore the data. How hard a rollback is depends on the data, not the files. Abandoned plugins get no fixes at all, so replace them.

What the 6.6 automatic rollback catches, and what it misses

The rollback added in WordPress 6.6 makes an internal request (a loopback) to the site's homepage after a plugin auto-update. If a PHP fatal error appears, it restores the previous version and emails the administrator.

There are failures it does not catch.

The rollback is only the first safety net. Combine it with layout and form checks and a pre-update backup, and only then widen automatic updates.

The update flow: back up, test, check, go live

Take high-impact updates through four steps. A staging environment is a copy of the live site at a different URL; many hosts can create one.

Steps 2 and 3 can run automatically; people look only when a difference appears. For 24 hours after step 4, shorten the monitoring interval and read the error log.

4. Planning PHP and server updates

PHP is the language WordPress runs on, and it lives on the server. It is not updated from the WordPress dashboard: you switch versions in your hosting control panel, or your server administrator does.

PHP support periods and WordPress compatibility

The table below combines the official PHP support periods with the WordPress PHP compatibility table.

Sites on 8.2 lose fixes in just over two months. If you upgrade, choose 8.4 or 8.5 for two to three years of headroom. PHP 8.5 needs WordPress 6.9 or later, and 8.4 needs 6.7 or later.

How to upgrade PHP, and the common failure

Switching PHP can break more than a core update, because older plugins may use code newer PHP rejects.

1. Check plugin and theme compatibility. Read each one's changelog
2. Upgrade PHP on staging first. Many hosts let you choose the version per site
3. Turn on the error log and open key pages and forms. Deprecation warnings are candidates to break in the next branch
4. Back up the day before, then upgrade live. Confirm how to switch back in the control panel
5. Read the error log for 24 hours afterwards. Problems with scheduled tasks and email sending appear late

The common failure: only scheduled posts or outgoing email stop after the upgrade. The site looks fine, so it surfaces days later as missing enquiries. Form-submission monitoring (section 7) catches this.

Server operating system and middleware

On a VPS or similar, operating system, web server and database updates are part of maintenance too. IPA's "20 points for securely operating websites" lists keeping these current and understanding the division of responsibility when using cloud services. Confirm in your contract where the provider's responsibility ends.

5. Designing backups: 3-2-1 and RPO/RTO

First decide how far back you need to be able to go; otherwise frequency and storage are chosen by feel.

What 3-2-1 means

3-2-1 means keeping at least three copies of your data, including the original, on two different types of storage, with one copy in a different location. CISA in the US, the NCSC (National Cyber Security Centre) in the Netherlands and IPA in Japan all recommend it. IPA added "take backups" to the first steps in its information security guidelines for small and medium-sized businesses.

For a website:

The last row reflects the offline copies and separation from production that CISA and the NCSC recommend as protection against ransomware. A location you can wipe from the same control panel as the live site does not count as "elsewhere".

Set RPO and RTO first

The NIST glossary defines the recovery point objective (RPO) as "the point in time to which data must be recovered after an outage". In other words, how much data you can afford to lose. The recovery time objective (RTO) is the maximum time you can be down. The NCSC explains RPO with an example: if backups run at 03:00 and an incident hits at 16:00, you lose the 13 hours in between.

A shorter RPO means more frequent backups; a shorter RTO means a better restore procedure and more practice. Here are guidelines by type of site.

These are DevNJ guidelines. The official WordPress documentation suggests weekly backups for sites that change little and daily for busy ones, and leaves the final schedule to how much you can afford to lose. Sites that store enquiries or orders in the database should back up the database more often than the files.

What to back up

The official WordPress documentation says you need both the files and the database. Files include core, plugins, themes, uploaded images, wp-config.php and .htaccess. The database lives outside the WordPress folder, so downloading the files does not include it.

The easily forgotten parts are settings that live outside the site.

DNS settings often vanish in migrations, so record them every time they change.

Retention and versions

Versions are how many past backups you keep. The official WordPress documentation recommends keeping at least three to five, and CISA recommends being able to roll back at least seven days. Tampering and injected malicious code can take days to notice.

DevNJ often keeps 14 daily, 8 weekly and 12 monthly backups. Long retention of personal data can conflict with the GDPR (the EU General Data Protection Regulation), so align retention with your privacy policy.

6. Restore tests: a backup only counts once you can restore it

The NCSC warns that backups are often first tested when actually needed. A success email does not guarantee a restore.

Technical tests and functional tests

The NCSC splits restore testing into two kinds. A technical test checks that the backup software reports success. A functional test restores everything and checks that the business can run on it.

A sudden change in size can be watched automatically: a backup half yesterday's size suggests a stopped job or deleted data.

The quarterly full restore

Restore to a staging environment at a different URL, not to the live site. Time it: that number is your real RTO.

1. Pick a version from a week ago. That also proves older versions work
2. Restore files first, then the database. That is the order the WordPress documentation gives; if credentials change, update wp-config.php
3. Check key pages, the admin area and forms. Look for missing images and garbled characters
4. Record how long it took. If it exceeds your target RTO, revise the procedure or the storage
5. Update the runbook the same day

CISA recommends revising RPO and RTO based on the results of restore exercises. A target only becomes a real number once you test it.

7. Uptime monitoring: what to check, and how often

Uptime monitoring checks from outside whether the site works and alerts when it does not; checks inside the server fall silent when the server goes down.

What to monitor

A homepage response alone is not enough, since a site can respond with an empty page.

The last row treats a missing report as an anomaly, catching backups and scheduled tasks that stop silently.

Uptime percentages and downtime

Uptime promises are easier to compare in minutes of downtime per 30-day month.

Per year, that is about 87.6 hours at 99%, 43.8 hours at 99.5%, 8.8 hours at 99.9%, 4.4 hours at 99.95% and 53 minutes at 99.99%. Five-minute checks suit up to 99.5%; above that, check every minute, from several locations at 99.99%.

With 5-minute checks and two consecutive failures as the trigger, it can take up to about 10 minutes to notice. If you promise 99.9% and notice 10 minutes late, you spend almost a quarter of the month's allowance just waiting for the alert. Set the promised uptime and the monitoring interval together.

Reducing false alarms

A common failure is so many false alarms that nobody reads the alerts any more. Three habits reduce them.

• Alert on consecutive failures, or failures from two or more locations
• Pause monitoring during planned work such as updates and migrations
• Split channels by urgency: "site down" to a phone, "certificate days remaining" to email

How downtime affects search

According to Google Search Central, 5xx and 429 errors make Google slow crawling, and URLs that keep returning server errors are eventually dropped from the index. Crawling recovers gradually once responses return to 2xx.

When robots.txt returns 5xx, the treatment depends on how long it lasts.

For planned downtime, Google recommends 503 for one to two days, and an informational page with status 200 for longer closures, warning that closures beyond a few days can take a long time to recover from in Search.

8. Watching SSL certificate and domain expiry

When certificates and domains expire, the site stops with certainty. Because the date is known in advance, monitoring can prevent almost all of it.

Certificates: shorter lifetimes and when to renew

Let's Encrypt suggests renewing at roughly two thirds of the lifetime, and recommends supporting ARI (ACME Renewal Information), which lets the certificate authority tell clients when to renew. A fixed 60-day renewal will no longer be enough for 45-day certificates.

Lifetimes follow the CA/Browser Forum schedule; renewal points apply the Let's Encrypt guideline. Businesses replacing paid certificates by hand need an automation method before March 2027, usually a certificate authority and server that support ACME (automated certificate issuance).

Monitor at two levels: watch below one third of the lifetime, alert below seven days, which keeps working as lifetimes change. Renewals tend to fail after DNS changes, migrations or adding a CDN, so check by hand after such work.

Domains: what happens when they expire

An expired domain stops email as well as the website. What happens depends on the type of domain.

gTLD notices are set by ICANN's Expired Registration Recovery Policy (ERRP); the .nl rules come from SIDN and the .jp rules from JPRS, with windows and fees varying by registrar. Recovery always costs a fee, and the site and email are down meanwhile. The most common cause of expiry is renewal notices going to a former employee or an unused address. Use a shared mailbox as the registrant contact, and once a year check auto-renewal and the payment card's expiry date.

9. Incident communication: who, when and what

An alert is useless if nobody knows who acts on it. ENISA's (the EU Agency for Cybersecurity) SME guide calls for an incident response plan with defined roles.

Order of communication and time markers

At DevNJ we think about incident communication in these stages. Times are guidelines and depend on the contract.

The key is leaving the "decision" stage to a person. Restoring from a backup can wipe enquiries and orders received in between, so it must never be decided automatically. Keep a yearly-reviewed list of contract holders, emergency contacts and two-factor devices for server, domain, DNS, email, payments and your agency.

Reporting when personal data is involved

If the incident was caused by unauthorised access and form submissions or member data may have leaked, you may be legally required to report it. Deadlines differ between Japan and Europe.

Article 32 of the GDPR requires the ability to restore access to personal data in a timely manner and regular testing, which backups and restore tests help demonstrate. Businesses with customers in both Japan and Europe should build their procedure around the shorter 72 hours.

10. Cost and effort ranges

The cost of automating maintenance varies widely with how far you go. The table below is a DevNJ estimate for a single WordPress site.

Reviewing differences and deciding on restores remain at every tier.

Outsourced at €80 an hour, set-up costs are as follows.

The first-year total adds twelve months of running costs to the set-up cost, excluding people's time.

Weigh this against what an outage costs. A site with 20 enquiries a month worth €500 each loses about €1,000 in a three-day outage, so tier 2 pays for itself by preventing one. If enquiries come mostly by phone, tier 1 may be enough.

11. Common failures

These failures all come from skipping the checks after setting things up.

The first two rows are the most common. "We take backups" does not mean "we can restore".

12. Japan and Europe compared

Running sites in both regions changes a few assumptions; these are differences in conditions, not a ranking.

For European sites, you may be asked whether backups are stored outside the EU. If your storage lets you pick a region, choosing one inside the EU keeps the explanation simple.

13. Three cases (fictional businesses)

Three fictional businesses show how the same approach gives different answers.

Company A: a Japanese manufacturer's English site for Europe

A catalogue site with about 10 form enquiries a month (RPO 1 day). Tier 2: database daily and files weekly to EU storage at another provider, plus one test submission every morning that alerts staff in Japan and the Netherlands.

Company B: a Japanese food webshop in the Netherlands

With 30 to 50 orders a day, it sets RPO 1 hour and RTO 2 hours, adding a daily off-site transfer to the host's hourly backups. Payment and stock plugins go through staging on Tuesday mornings; avoiding weekend updates keeps the host's support desk available.

Company C: a bilingual Japanese–Dutch professional services firm

Its consultation requests contain personal data. At tier 1, it stopped storing form submissions on the site: less personal data on the site means less retention and smaller breach impact. Expiry monitoring matches tier 2.

14. Rolling it out in four weeks

Maintenance automation can take shape in about four weeks. Set a deliverable for each week.

1. Week 1: record the current state. Versions, backups, expiry dates and contracts on one page
2. Week 1: set RPO and RTO with the person in charge (section 5)
3. Week 2: make backups 3-2-1. Off-site storage, versions, size alerts
4. Week 2: sort plugins into automatic, after staging, and replace (section 3)
5. Week 3: set up the four checks plus alerts for missing backup reports
6. Week 3: fill in the communication table (section 9) and contact list
7. Week 4: run the first full restore to staging and time it
8. From week 4: schedule checks, monthly for alerts and logs, quarterly for a restore

The first restore test almost always trips over something. Finding it before a real incident is the whole point of week 4.

15. What not to do

These are settings and decisions worth avoiding when automating maintenance.

Automation means spending a little effort up front so you spend less later.

16. Checklist

After rollout, check these items monthly and quarterly.

• WordPress core is on the latest branch, with minor updates automatic
• PHP is 8.3 or higher, and you know when its security fixes end
• RPO and RTO are set as numbers and agreed by the person in charge
• There are at least three backup copies, one at another provider and location
• Once a quarter, you restore everything to another environment and record the time
• Response, text string, certificate and domain are monitored from outside
• Certificates renew automatically, with two levels of remaining-days alerts
• The order of incident communication and who decides on restores are set
• The procedure records breach reporting deadlines (72 hours; 3–5 days)

17. Summary

• Maintenance automation means building the task and the mechanism that notices its failure as a pair
• Decide auto-update scope by failure impact and ease of rollback; check payments, forms and page builders on staging first
• PHP 8.2 security fixes end on 31 December 2026; if you upgrade, choose 8.4 or 8.5
• Set RPO and RTO first, store backups 3-2-1, and actually restore once a quarter
• Monitor response, text string, certificate and domain from outside, alerting after two consecutive failures
• The maximum certificate lifetime reaches 47 days in March 2029; manual renewal cannot keep up
• People keep restore decisions and customer communication; with personal data, work to 72 hours

Sources

WordPress and PHP

• Upgrading WordPress — WordPress Developer Resources: types of automatic update, defaults, constants
• Plugin and themes auto-updates — WordPress.org Documentation: the 5.5 screens, twice-daily runs, notifications
• Merge Proposal: Rollback Auto-Update — Make WordPress Core: how the 6.6 rollback works
• WordPress Backups — WordPress Developer Resources: what to back up, frequency, versions, restore order
• Hardening WordPress — WordPress Developer Resources: older versions receive no security updates
• Requirements — WordPress.org: recommended environment
• PHP Compatibility and WordPress Versions — Make WordPress Core: PHP support by WordPress branch
• Releases — WordPress.org: latest release dates
• Supported Versions — PHP: support deadlines by branch

Certificates and domains

• Ballot SC-081v3 — CA/Browser Forum: the ballot shortening maximum lifetimes
• Service changes for shorter maximum certificate lifetimes — JPRS (Japanese): the 200, 100 and 47-day schedule
• Decreasing Certificate Lifetimes to 45 Days — Let's Encrypt: the 64 and 45-day schedule and renewal guidance
• Ending Support for Expiration Notification Emails — Let's Encrypt: the end of expiry emails
• Expired Registration Recovery Policy — ICANN: gTLD notices and grace period
• Undoing the cancellation of a domain name — SIDN: the .nl quarantine
• JP domain name lifecycle — JPRS (Japanese): .jp cancellation and recovery

Backup and security guidance

• Back Up Business Data — CISA: 3-2-1 and restore exercises
• Een back-up strategie opstellen (Drawing up a backup strategy) — NCSC: 3-2-1 and RPO/RTO examples
• Hoe test ik een back-up? (How do I test a backup?) — NCSC: two kinds of restore test
• Recovery point objective — NIST CSRC Glossary: definition of RPO
• Recovery time objective — NIST CSRC Glossary: definition of RTO
• Information security guidelines for SMEs — IPA (Japanese): first steps including backups
• 20 points for securely operating websites — IPA (Japanese): server updates and division of responsibility
• Cybersecurity guide for SMEs — ENISA: 12 steps for SMEs

Search and reporting

• HTTP status codes, network and DNS errors — Google Search Central: how 5xx errors are handled
• How Google interprets the robots.txt specification — Google Search Central: robots.txt returning 5xx
• Pausing your online business — Google Search Central: planned downtime
• This is how you report a data breach — Autoriteit Persoonsgegevens: reporting within 72 hours
• Responding to data breaches — Personal Information Protection Commission (Japanese): reporting deadlines
• Regulation (EU) 2016/679 (GDPR) — EUR-Lex: Articles 32 and 33

All sources were checked on 24 October 2026. Versions, deadlines and prices change, so confirm the latest information on the official sites before acting. Costs, effort and guidelines by type of site are DevNJ's practical estimates and vary with site size and contract.