The Complete Server Management Checklist for 2026

Security & Access

Security tasks are the ones most likely to get deferred because nothing visibly breaks when you skip them — until it does, all at once. Run through these on at least a monthly cadence.

—Apply OS security patches. On Ubuntu, apt update && apt list --upgradable shows what's pending, and enabling unattended-upgrades keeps security patches flowing without you having to remember.

—Audit SSH access — disable root login, enforce key-only auth in sshd_config, and revoke keys for anyone who's left the team.

—Review firewall rules with ufw status verbose or, on a CSF-managed box, csf -l — close any port that isn't actively serving something.

—Check for brute-force patterns in /var/log/auth.log or via fail2ban-client status sshd, and confirm fail2ban jails are actually enabled, not just installed.

—Check SSL certificate expiry dates — openssl x509 -enddate -noout -in /path/to/cert.pem or certbot certificates if you're running Let's Encrypt manually.

—Review user and sudo accounts quarterly. Every account with access is an attack surface — remove what's not needed.

Backups & Disaster Recovery

A backup you haven't verified is a guess, not a plan. This section is about closing the gap between "a backup job ran" and "we could actually recover from this."

—Confirm backups actually completed — check the file exists with today's timestamp and a plausible file size, not just that the cron log says "success."

—Test-restore a backup at least once a quarter, ideally onto a throwaway server. An untested backup only tells you a job ran, not that it works.

—Verify backups are stored somewhere other than the disk they're protecting — a backup living on the same server survives nothing that actually takes the server down.

—Check your retention policy still matches your recovery needs — enough history to roll back a bad deploy from two weeks ago, not just yesterday.

—Back up more than the database. Configs, uploaded files, wp-content, cron definitions, and SSL certificates all need to be part of the set, or a restore leaves you half-recovered.

Performance & Resource Health

Resource exhaustion rarely announces itself in advance. It builds quietly until disk, memory, or CPU runs out all at once — check these weekly, not after something already broke.

—Check disk usage with df -h. A full disk takes down MySQL writes, log rotation, and deployments in one shot — leave real headroom, not 2% free.

—Check swap usage with free -h. Heavy, sustained swapping means it's time to add RAM or find a memory leak, not tune around it.

—Review slow query logs on MySQL/MariaDB and fix or index the queries that show up repeatedly rather than just throwing more RAM at the problem.

—Test Nginx configuration changes with nginx -t before reloading. A broken config on reload leaves the old process running until you notice — nginx -t catches syntax errors before they matter.

—Check PHP-FPM pool settings — pm.max_children and related values should scale with actual traffic, not whatever the default install shipped with.

—Watch load average against core count with uptime — a load average consistently above your core count means the server is queuing work, not just busy.

Monitoring & Alerting

Monitoring only earns its keep if you actually look at it, and if the alerts land somewhere a human will see them in time to act.

—Track CPU, memory, and disk trends over time, not just the current snapshot — a slow climb over three weeks is the warning a single reading never gives you.

—Run uptime checks from an external service, not just from the server itself — a server can't reliably report that it's unreachable.

—Route alerts somewhere someone actually checks — a Slack channel or SMS, not an inbox filter nobody opens.

—Confirm log rotation is actually running, not just configured. Check /etc/logrotate.d/ and verify old logs are genuinely being compressed and pruned with logrotate -d /etc/logrotate.conf (dry run) or by checking file timestamps directly.

—Revisit alert thresholds quarterly — a threshold set when the site had a tenth of the traffic will either go silent or fire constantly today.

Housekeeping & Cleanup

None of these are urgent on any given day, which is exactly why they pile up. Set a recurring reminder and clear them in one pass.

—Audit PHP versions across every site on the server — anything still running an end-of-life PHP version is a standing security liability, patched or not.

—Remove unused packages and stale cron jobs left behind by decommissioned projects.

—Rotate API keys, database credentials, and any service tokens that are old enough that nobody remembers issuing them.

—Clean up old release and deploy directories — they're a common, invisible cause of "why is the disk full again."

—Review DNS records for entries still pointing at servers you've since decommissioned or migrated away from.

—Check for outdated CMS core and plugin versions, especially on WordPress sites where plugin sprawl is the norm.

Quick-Reference Summary

If you only run one pass a month, hit these five first: patch the OS, verify a backup actually restores, check disk and swap headroom, confirm alerts are routed somewhere live, and audit PHP versions across every site. Everything else on this list matters, but these five are the ones most likely to turn into an outage if they slip. A fair amount of it — automatic SSL renewal, real-time resource monitoring, scheduled backups with configurable retention, and PHP version management through EasyPHP — is handled by CloudStick out of the box, which is really the point of a checklist like this: knowing exactly what still needs a human, and what doesn't.