A maintenance routine that keeps a CMS site boring

Sites rarely fail because of a single dramatic event. They fail because nothing was done for two years and then everything had to be done at once.

Weekly

• Check for security releases in core and contributed code, and apply them.
• Skim the error log. Recurring warnings are defects that have not surfaced yet.
• Confirm backups ran and that the file is the size you expect.

Monthly

• Apply non-security updates on staging, then production. Small and frequent beats large and rare.
• Review user accounts and roles; remove people who have left.
• Check disk, database growth and queue depth against last month.

Quarterly

• Restore a backup somewhere else. An untested backup is a hypothesis, not a safety net.
• Audit modules and plugins — remove anything disabled, abandoned or unused.
• Review performance and Core Web Vitals against the previous quarter.
• Check the end-of-life dates of PHP, the database and the CMS major version.

The one that gets skipped

Keep staging genuinely close to production: same PHP version, same database engine and version, a recent copy of the data. Most “it worked on staging” incidents are really “staging was three years out of date”.

None of this is interesting work. That is the point — it is what buys you uneventful launches.