Websites do not fail suddenly. They fail after a year of nobody applying updates, a backup job that stopped in March, and a domain nobody renewed. Each is preventable by a short check on a schedule.
This is that schedule, split by how often each item is worth doing.
Monthly: fifteen minutes
Check the updates were applied. Automatic updates can stop silently, confirm the site is on current versions rather than assuming.
Read the 404 log. A rise means broken links, usually from your own site. How to Find and Fix Broken Links on Your Site goes into acting on it.
Look at disk and bandwidth. Both grow steadily, and both fail hard at the ceiling.
Check the backup ran, and that its size is plausible. A backup a tenth of its usual size is a backup of nothing.
Skim the error log. A recurring error nobody has reported is a fault waiting for the right visitor.
Quarterly: an hour
Restore a backup to a test location. Not check that one exists, restore it. This is what finds the excluded directory, the database too large to import, and the job that stopped weeks ago. How to Restore a WordPress Site from Backup goes into doing it.
Review who has access. Administrator accounts, FTP users, API tokens. Remove anything you cannot account for: contractors, old integrations, people who left.
Delete unused plugins and themes instead of leaving them deactivated. Deactivated files are still on disk and still reachable.
Test the contact form from outside your own network, and confirm the message arrives in an inbox instead of a spam folder. This is the failure nobody reports.
Reboot a VPS or dedicated server deliberately, so boot problems surface while you are watching. How to Plan and Run Server Maintenance Windows explains the window.
Annually: half a day
Check every expiry date. Domain, certificates, and every third-party subscription the site depends on. Confirm auto-renewal is on and the card is current, auto-renewal with a dead card fails exactly like no auto-renewal.
Review the PHP version. Versions stop receiving security fixes on a published schedule, and moving takes planning instead of a click. For the extension trap, see MultiPHP Manager and Choosing a PHP Version.
Reassess the plan. Is the site using what you pay for, or has it outgrown it? Both directions cost money. How to Monitor Your Hosting Resources walks through the figures.
Read your own privacy notice against what the site actually collects now. New plugins add new third parties, and the notice drifts out of date without anyone changing it.
Update the documentation. What each plugin is for, where custom code lives, which accounts exist. You will need it within the year.
The four things that actually take sites down
Worth separating, because they are the ones to protect first if you do nothing else on this list.
An expired domain. Everything stops at once, site, mail, certificates, and recovery gets expensive quickly. What Happens When a Domain Expires explains the stages.
A full disk. Uploads, sessions, database writes and mail fail simultaneously, and none of the errors mention disk.
An unpatched vulnerability. The most common route to a compromised site by a wide margin.
A backup nobody tested. Which turns any of the above into a much longer day.
Set the alerts so the list matters less
Most of this is checking for things that could tell you themselves.
Uptime monitoring from outside, alerting to an address not on this server. Certificate and domain expiry warnings. A disk alert at 80%. A notification when an automatic update runs or fails.
With those in place the monthly check becomes confirmation rather than discovery. For making them arrive, see How to Set Up and Read Uptime Monitoring.
Write down when you last did each
A dated list, in the same place as your site documentation.
Its value is answering "when did we last test a restore" without guessing, and making it obvious when something has slipped, which is usually the quarterly items, because nothing prompts them.
If you look after sites for other people
The same schedule, and one addition: say which of these you are doing and which you are not.
A client who believes you are applying updates while you believe they are is the arrangement behind most compromised client sites. Put it in writing, per site, and revisit it annually. How to Manage a Portfolio of WordPress Sites goes into doing it at scale.
One item belongs on this list and is almost never on it: confirming the domain's registered contact address still reaches somebody. There is more in What Happens When Domain Contact Details Are Unverified.
Check the things that expire
Most unplanned outages are not failures. They are dates that passed while nobody was looking.
whois example.com | grep -iE 'expir' echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate dig _dmarc.example.com TXT +short
Four dates matter and they renew through different systems: the domain, the certificate, the hosting plan, and the payment card that renews the first three.
The card is the one that catches people, because it expires quietly and takes everything else with it when it does. Checking it takes a minute and it is the single highest value item on any maintenance list. Domain auto-renewal goes into why enabling it is not sufficient on its own.
Confirm the backups by restoring one
A checklist item that reads "check backups exist" is satisfied by a directory listing, which is not the thing you need to be true.
ls -lt /backup/ | head -3 tar -tzf /backup/latest.tar.gz | head -5
Once a year, restore a real backup to somewhere that is not the live site and open it. You are checking three things: that the archive extracts, that the database imports, and how long the whole thing took.
The duration is the number worth writing down, because it is the answer to the only question anyone asks during an outage. An untested backup is a belief, and the annual pass is where it becomes a fact.
Read what the site actually returns
Sites decay in ways that are invisible from the front page, and a short sweep finds most of it.
curl -s https://example.com/sitemap.xml | grep -o 'https://[^<]*' > /tmp/u.txt
while read u; do printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$u")" "$u"; done < /tmp/u.txt | grep -v '^200' | head
What surfaces is usually a handful of pages that were removed without a redirect, an image directory that moved, or a form that now points somewhere that no longer exists.
Then check the error log for the month. A single fault repeating thousands of times is both a broken feature and a performance cost, and it never announces itself. Understanding cPanel error logs deals with reading it.