On this page

Joomla Maintenance Checklist: Daily to Yearly Tasks

12 August 2026

Nobody plans to neglect a website. It happens one skipped week at a time: the update that could wait, the backup nobody checked, the log nobody read. A year later the site is three versions behind, the newest backup is from March, and a routine problem has become an expensive one. The cure is not heroic effort - it is a checklist with a rhythm.

This article turns Joomla maintenance into a concrete schedule: what must run automatically every day, what a human checks weekly, monthly, quarterly, and yearly, and how to keep the routine alive instead of abandoned. It draws together the Focus On articles on updates, backups, security hardening, performance, overrides, and troubleshooting into one maintenance calendar - each deep topic lives in its own article; here they get their date and their order.

A maintained site has boring weeks. That is the whole point.

The goal is simple: give you a maintenance rhythm you can actually keep - fifteen focused minutes a week, and a site that quietly stays healthy for years.

1. The Basics

1.1 Maintenance versus Firefighting

Every site owner pays for maintenance - the only choice is the currency. Pay in small scheduled portions (minutes per week) and problems stay small: updates apply cleanly, backups exist when needed, odd log entries get noticed early. Skip the portions and you pay in emergencies: hacked sites, failed updates with no backup, rankings lost to months of broken links. The troubleshooting article exists for bad days; this article exists to make bad days rare.

1.2 The Rhythm at a Glance

Cadence	Who	Core question
Daily	Automation	Is everything running, and would I hear it if not?
Weekly	Human, ~15 minutes	Updates, backups, alerts: anything waiting for me?
Monthly	Human, ~30 minutes	Trends: logs, search data, disk, anything drifting?
Quarterly	Human, ~2 hours	Audits: users, extensions, restore drill, full crawl.
Yearly	Human, half a day	Strategy: hosting, PHP roadmap, documentation, cleanup.

1.3 The Maintenance Log

Keep one running document per site: date, what you did, versions involved, anything odd. It takes one line per session and pays for itself the first time something breaks - "what changed?" (the troubleshooting article's first question) gets answered by reading instead of remembering. It is also your proof of diligence for clients.

2. Daily: What Runs Without You

2.1 Automation First

The daily layer belongs entirely to machines. Your job is not to do daily tasks - it is to set them up once and make their silence audible. The building blocks, each covered in its own article:

Job	Mechanism
Backups (files + database, off-site)	Backup extension or script on cron - the backups article's 3-2-1 setup.
Update notifications	Task - Update Notification plugin via the Task Scheduler.
Session cleanup	`sessiongc` task plugin.
Log rotation and pruning	`rotatelogs` and `deleteactionlogs` task plugins.
Stale lock cleanup	`globalcheckin` task plugin.
Oversized file detection	`checkfiles` task plugin.
Uptime monitoring	External monitor pinging the site (and ideally one API endpoint) - include certificate expiry checking, which most monitors do for free.
Core patch releases (optional)	Joomla's automated updates service, with the backup check on.

The uptime monitor does not need to be a paid service: Uptime Kuma - free, open source, self-hosted in a Docker container - watches any number of sites (HTTP, keyword checks, certificate expiry) and pushes alerts to mail, Telegram, Slack, and dozens of other channels. It is what I run for my own and my clients' sites: one dashboard, every site, and the silence-is-alarm principle made visible.

2.2 Trigger the Scheduler Properly

All the task plugins above depend on the Task Scheduler actually firing. Wire it to a real server cron job or the web-cron URL - not to backend visits, which stop the day you stop visiting. This one configuration choice decides whether your "daily" layer exists at all.

2.3 Silence is a Signal

Every automated job should report somewhere - mail, a monitoring channel - and the rule from the backups article applies to all of them: treat silence as the alarm. A dead cron job sends no failure mail. Your weekly check (next section) includes verifying the reporters still report.

3. The Weekly Quarter Hour

3.1 The Checklist

Updates: open System → Update → Joomla and → Extensions. Install what is pending - after the pre-update ritual below when it is more than a patch.
Backup freshness: check the age and size of the newest off-site backup. Newer than your schedule promises, plausible size? Ten seconds.
Alerts: read the week's notification mails - update notices, backup reports, uptime alerts. Anything unexplained goes on the log.
Failed logins: one glance at the failed-login log (the System - Log plugin writes it). A burst means the security article's section 5.2 countermeasures earn their keep.
Smoke test: load the homepage, submit one form - and confirm its mail actually arrived. Silently broken email is among the most common unnoticed failures, and monitoring rarely sees it.

3.2 The Pre-Update Ritual

For every update beyond a trivial patch, the ritual from the backups article: fresh backup, read the release notes, update, test the site. And the step almost everyone skips, from the overrides article: after a core update, open the template's Updated Files list and reconcile your overrides - stale overrides silently keep old bugs and old security gaps alive.

3.3 Why Weekly and Not "When I Get Around to It"

The security article documented the shrinking window between a security release and its exploitation - AI-assisted vulnerability discovery accelerated both sides. Weekly is the slowest cadence that keeps you inside that window for most releases; critical security updates should not even wait for the weekly slot.

4. The Monthly Half Hour

4.1 The Checklist

Action log review: skim Users → User Actions Log. Unexpected installs, permission changes, or logins are worth a question.
Search Console: coverage errors and the Core Web Vitals field data (the performance article explains why field data is the number that counts). Look for drift, not perfection.
Disk and database: hosting panel disk usage and the largest database tables. Growth is normal; sudden jumps are not.
Backup storage: look at the off-site backup folder with your own eyes - generations present, retention rotating, no silent stop in March.
VEL glance: check the Vulnerable Extensions List against anything you run - especially extensions whose developers have gone quiet.
PHP version check: still on an actively supported PHP? Plan the switch before the host forces it.
Deliverability glance: send a test mail (password reset works well) to an external mailbox and check it passes SPF, DKIM, and DMARC. DNS and hosting changes quietly break mail authentication - the email deliverability article explains the checks.

4.2 Trends Beat Snapshots

The monthly session is about direction: is the site drifting somewhere? A slowly filling disk, slowly rising response times, slowly growing failed-login noise - each is invisible in a weekly glance and obvious in a monthly comparison against your maintenance log's previous entry.

5. The Quarterly Audit

5.1 The Checklist

User audit: every account justified, departed people removed, Super Users countable on one hand, MFA coverage complete. The ACL article's Debug User view settles doubts.
Extension audit: uninstall - not disable - what nobody used this quarter. Fewer extensions, smaller attack surface, faster updates (the security and performance articles agree on this one).
Restore drill (every second quarter): restore the newest off-site backup to a scratch location and walk the checklist from the backups article. Note the recovery time.
Full crawl: a Screaming Frog pass over the site - broken links, redirect chains, duplicate titles, orphan pages - before Google finds them (the SEO article's section 10.4).
Performance measurement: the performance article's three key pages against your logged baseline. Regressions get a ticket, not a shrug.
Override review: any Updated Files entries left unreconciled? Any overrides now identical to core that can be deleted?
Malware scan and file integrity: run an external malware scan of the rendered site, and verify the files against version control (git status) or a clean Joomla download. Web shells hide as legitimate-looking PHP files; comparison finds what scanners miss.
Accessibility spot check: walk key pages with the keyboard, verify form labels and contrast, and let Joomla's built-in Accessibility Checker plugin (jooa11y) flag issues for editors. Content and template changes erode accessibility quietly - especially after override work.

5.2 The Audit Mindset

Quarterly work is adversarial: you are trying to find what the routine missed. Assume something drifted - an account that should be gone, an extension nobody remembers, a redirect chain from the last restructuring - and go look for it. Finding nothing is a pass, not a wasted afternoon.

6. The Yearly Half Day

6.1 The Checklist

Hosting review: does the stack still fit - PHP roadmap, database version, isolation, price? The performance article's hosting questions, asked again with a year of data.
Joomla roadmap: where does your version sit in the support lifecycle? Plan major migrations a year ahead, not the month support ends.
Credential rotation: database password, API tokens, deploy keys, the accounts in your DR document. Rotate what leaked-in-theory; remove what nobody uses.
DR documentation: reread the disaster recovery document from the backups article. Are the locations, credentials, contacts, and steps still true? Could a colleague still restore without you?
Privacy and retention: backup retention versus your privacy policy, user data that should have been purged, mail lists against reality - the GDPR points from the backups and privacy articles.
Renewals inventory: domains, certificates (if not auto-renewed), licences, the backup storage subscription. Calendar the expiry dates.
Content pruning: archive or redirect what is obsolete; the crawl from the quarterly audit tells you what nobody links to anymore.

6.2 The Yearly Question

End the session with one strategic question: if this site broke beyond repair tomorrow, what would we rebuild differently? The answer usually names next year's improvement project - and occasionally saves you from maintaining something that should be replaced.

7. Keeping the Routine Alive

7.1 Make It Trivially Easy to Start

Routines die from friction, not from laziness. Put the checklist where you will trip over it: a recurring calendar block with the checklist in the invite, a pinned note, a template page in your maintenance log. The fifteen-minute session must be startable in fifteen seconds.

7.2 Batch Sites, Not Tasks

Maintaining several sites? Do one site's full weekly check, then the next - not "all updates everywhere, then all backups everywhere". Per-site batching keeps the maintenance log coherent and catches per-site oddities that task-batching glosses over. A central dashboard such as YourSites (see the security hardening article) makes the batch efficient: one screen shows which sites have updates waiting, so the weekly round starts with a list instead of a login tour.

7.3 When You Fall Behind

You will - holidays, projects, life. The recovery is a triage, not a guilt trip: security updates first, then the backup check, then one full weekly pass, then resume the rhythm. A month of missed maintenance is an afternoon of catch-up; do not let the gap become the excuse for a bigger gap.

8. Under the Hood (Developer View)

8.1 The Checklist as Commands

Most of the weekly and monthly checks have CLI equivalents, which makes them scriptable across a fleet:

php cli/joomla.php core:update:check        # core update available?
php cli/joomla.php extension:list           # inventory, with ids
php cli/joomla.php maintenance:database     # schema still consistent?
php cli/joomla.php config:get               # verify configuration state
php cli/joomla.php scheduler:run            # tasks fire outside web cron
ls -lh /path/to/backups | tail -5           # backup age + size
git -C /path/to/site status --short         # unexpected file changes?

A small wrapper script that runs these per site and mails one combined report turns a ten-site weekly check into reading one email. Build alerting on absence as well as failure - the recurring theme of this article.

8.2 Version Control as a Maintenance Tool

A site whose templates and overrides live in git gives maintenance superpowers: git status flags unexpected file changes (drift or compromise), git diff reconciles overrides after updates in minutes, and the commit history becomes the technical half of your maintenance log. The overrides article recommends this; the quarterly audit is where it pays off.

8.3 Staging Discipline

For business-critical sites, the weekly update slot points at staging first: restore drill output doubles as the staging copy (the backups article's bonus), updates run there, the smoke test runs there, and production follows a day later. The maintenance rhythm absorbs the extra step without changing shape.

9. Maintenance and the Web Services API

For anyone maintaining multiple sites, the API turns checks into monitoring. A fleet script with a minimal-rights token (the ACL article's dedicated-API-user recipe) can ask each site for its Joomla version, verify it responds at all, and confirm content endpoints answer - your uptime monitor with insight. Combined with the CLI report from section 8.1, the weekly quarter hour scales to dozens of sites without growing.

Two API-specific items belong on the checklist rather than running it: rotate API tokens in the yearly credential pass, and review which groups hold API login permission in the quarterly user audit. Integrations have a way of outliving the projects that created them; the audit is where forgotten tokens get found and revoked.

10. SEO and Metadata

Search rankings are compound interest on reliability, and maintenance is what keeps the interest compounding. Every layer of the rhythm has an SEO face: the weekly update habit keeps the site off blocklists (the fastest ranking destroyer there is), the monthly Search Console review catches coverage and Core Web Vitals drift while it is still cheap to fix, and the quarterly crawl removes the broken links and redirect chains that quietly bleed authority.

The maintenance log helps here too: when rankings move, the first question an SEO analysis asks is "what changed, and when?" - and your log answers it to the day. Sites that are maintained on a rhythm rarely have SEO emergencies; they have small notes in a monthly review instead.

11. Common Mistakes and Pitfalls

11.1 The Checklist That Was Never Scheduled

Symptom: everyone agrees maintenance matters; nobody has it in their calendar; nothing happens.

Fix: a recurring calendar block with the checklist inside it, owned by one named person. Unowned maintenance is unmaintained.

11.2 Checking Without Acting

Symptom: the update notice is read weekly - and the update installed quarterly. The check became a ritual detached from its purpose.

Fix: every check ends in an action or a logged decision ("update X postponed until Y because Z"). A check with no possible consequence can be deleted from the list.

11.3 Alert Fatigue

Symptom: forty automated mails a week, all archived unread - including the one that mattered.

Fix: fewer, better signals. One combined report beats ten separate ones; alerts only for things needing action; and the silence-is-alarm principle for the rest.

11.4 Everything Updated at Once, Nothing Tested

Symptom: core plus eleven extensions updated in one go; the site breaks; nobody knows which update did it.

Fix: backup first, update in small groups, test between groups. The troubleshooting article's one-change-at-a-time rule applies to maintenance too.

11.5 The Immortal To-Do

Symptom: "migrate to supported PHP version" has appeared in twelve consecutive monthly reviews.

Fix: recurring findings get promoted to projects with a date, or explicitly accepted as risk in the log. The checklist is for checks, not for storing postponed decisions.

11.6 Maintaining the Site, Forgetting the Safety Net

Symptom: updates are punctual, the site is healthy - and the backup automation died eight months ago, unnoticed.

Fix: the meta-rule of this article: monitor the monitors. Backup freshness is a weekly check precisely because backups fail silently.

12. Best Practices

If you remember only a few things from this article, remember these:

Automate the daily layer completely, and make silence from any automation an alarm.
Fifteen minutes weekly, scheduled and owned: updates, backup freshness, alerts, failed logins, smoke test.
Never update without the ritual: backup, release notes, update, test - and reconcile overrides after core updates.
Monthly is for trends, quarterly for audits (users, extensions, restore drill, crawl), yearly for strategy and documentation.
Keep a one-line-per-session maintenance log; it answers "what changed?" forever.
Batch by site, not by task; recover from gaps with triage, not guilt.
Promote recurring findings to dated projects - a checklist is not a parking lot.
Script what repeats (CLI + API) once you maintain more than a couple of sites.

13. Quick Reference

DAILY (automated - set up once, monitor forever)
  [ ] off-site backup ran           [ ] scheduler tasks fired
  [ ] uptime + cert expiry monitored  [ ] notifications flowing
  tasks: sessiongc rotatelogs deleteactionlogs
         globalcheckin checkfiles updatenotification

WEEKLY (~15 min)
  [ ] System > Update: core + extensions (ritual if big)
  [ ] newest backup: age + size plausible
  [ ] read the week's alerts - anything unexplained?
  [ ] failed-login log: bursts?
  [ ] smoke test: homepage + one form + its mail arrived
  ritual: backup > release notes > update > test > overrides
          (Updated Files list after core updates)

MONTHLY (~30 min)
  [ ] action log skim               [ ] Search Console: CWV + coverage
  [ ] disk + database growth        [ ] backup generations rotating
  [ ] VEL vs installed extensions   [ ] PHP still supported?
  [ ] deliverability: test mail passes SPF + DKIM + DMARC
  compare against last month's log entry - look for drift

QUARTERLY (~2 h)
  [ ] user audit: accounts, Super Users, MFA coverage
  [ ] extension audit: uninstall the unused
  [ ] restore drill (every 2nd quarter) - note recovery time
  [ ] full crawl: links, redirects, titles, orphans
  [ ] performance vs baseline       [ ] override cleanup
  [ ] malware scan + file integrity (git / clean download)
  [ ] accessibility: keyboard walk + jooa11y checker

YEARLY (half day)
  [ ] hosting + PHP roadmap         [ ] Joomla lifecycle position
  [ ] rotate credentials + API tokens
  [ ] DR document still true? colleague-restorable?
  [ ] retention vs privacy policy   [ ] renewals calendared
  [ ] content pruning               [ ] "rebuild differently?" question

ALWAYS
  one line in the maintenance log per session
  every check ends in action or logged decision
  silence from automation = alarm

14. Summary

Joomla maintenance is not a skill problem - every task in this article is explained in depth elsewhere in this series. It is a rhythm problem, and the rhythm is learnable:

Daily belongs to automation: backups, scheduler tasks, monitoring - with silence treated as an alarm.
Weekly is a quarter hour: updates with the ritual, backup freshness, alerts, failed logins, a smoke test.
Monthly reads trends: logs, Search Console, disk, backup generations, the VEL.
Quarterly audits: users and MFA, extensions, the restore drill, a full crawl, performance against baseline.
Yearly is strategy: hosting and version roadmaps, credential rotation, documentation, retention, pruning.
Always: one log line per session, actions not just checks, and recurring findings promoted to real projects.

The fifteen weekly minutes are the whole trick. Sites maintained on this rhythm skip the dramatic chapters of the troubleshooting article almost entirely - their problems are caught as notes in a monthly review, not as outages on a Friday evening.

And if your site has already accumulated the deferred months - versions behind, backups unverified, accounts unaudited - the way back is one structured catch-up pass through exactly these checklists, hardest risks first. Setting that up, and handing over a rhythm that keeps itself, is among the most valuable half-days a Joomla specialist can deliver: everything after it is boring weeks, which is precisely the goal.