Most Drupal maintenance checklists fail in one of two ways: they are a backup schedule wearing a trench coat, or they are an encyclopedia that no one has ever finished on a Tuesday afternoon. A working checklist sits between those failures — bounded enough to actually run every month, and honest about which areas it covers. This article defines the nine areas that belong on a real Drupal maintenance checklist, the cadence that keeps each one cheap, and the three items that look like maintenance but belong to different routines. If your team already runs a a regression checklist before each minor release, keep it separate: regression checking is about catching change, maintenance is about preventing decay, and mixing them is how both get skipped.
The guiding rule: every item on the checklist must answer “what breaks if this is skipped for three months?” with something concrete. If the answer is vague, the item does not belong.
The Nine Areas That Belong On The Checklist
One: core and module updates, reviewed monthly and applied on a schedule rather than whenever a security release lands mid-week. Two: backups that are verified by restoration, not by a green dashboard icon — a backup you have never restored is a hypothesis. Three: log review — the Drupal dblog, the web server error log, and the PHP error log get a fifteen-minute skim, because slow errors are the ones that become outages. Four: user and permission audit — who gained admin since last month, which service accounts exist, are there accounts that should have been removed with a contractor. Five: performance against a a performance budget for a Drupal theme, because budgets decay silently and the checklist is the cheapest place to notice. Six: security monitoring — file integrity checks, failed login patterns, and whether any module on your stack appeared in a new advisory. Seven: content housekeeping at the edges that affect operations — orphaned files, overflowing log tables, scheduled jobs that stopped firing. Eight: environment hygiene — disk usage trends, certificate expiry dates, cron actually running and on schedule. Nine: a written note of anything deferred, because a checklist with no memory is how the same item gets deferred for a year. Nine areas, monthly cadence, each with an owner.
Worked application: a university department site with one part-time maintainer adopts the nine-area list as a first-Monday routine. Month one surfaces a contractor account never disabled, a log table that had grown to several gigabytes, and an update to a views module deferred twice. Month three, the restore test catches a broken backup job that the dashboard had reported as fine — the one moment the checklist pays for a year of itself in a single catch.
Cadence And Sizing: Monthly, Short, Owned
Cadence beats thoroughness. A monthly pass through nine areas, capped at half a day, outperforms a quarterly deep clean, because most decay is linear and cheap to reverse early. Size the checklist to the team you actually have: a solo maintainer runs the lean version — updates, restore-tested backups, logs, and the security skim — and treats the rest as quarterly. Write each item as a verb with a done-definition: “restore last night’s backup to staging and confirm the front page loads,” not “check backups.” Assign an owner per area even if every owner is the same person, because the day the team grows, the checklist should not need rewriting. And keep a changelog of what the checklist itself caught; six months of catches is the argument for its budget that no amount of best-practice citation can make.
Two sources do the heavy lifting for the update and security items. The Drupal security advisory feed is the canonical list of which modules have published advisories, and the monthly checklist should include a two-minute scan of it against your own module list — that single habit is what turns item six from a vague worry into a concrete yes-or-no answer, and it costs nothing but the two minutes. Pair the feed with a simple run-log — date, items completed, anything deferred and why — kept in the same place as the checklist itself. The run-log is what makes the routine auditable: when a director or a client asks what maintenance has actually done this year, the answer is a list of dated entries rather than an assurance, and a new maintainer can read six months of entries instead of performing archaeology on the server to learn how the site has behaved.
Store the checklist where the next person will actually find it — a README in the site repository beats a wiki page unopened since launch — and keep the monthly run notes in the same file, so the checklist and its history live in one obvious place that survives staff changes.
What A Maintenance Checklist Deliberately Excludes
Three things get left off on purpose. Feature work is not maintenance — the moment the checklist includes “improve the contact form,” the maintenance day becomes a development day and the updates queue silently. Major version upgrades are not maintenance — they are projects with planning, staging, and rollback, and they deserve planning a Drupal major upgrade as their own exercise rather than a line item next to log review. And redesign work is not maintenance, even when it touches templates; mixing visual change into a stability routine is how regressions ship with confidence. The checklist exists to keep a site boring. Boring sites are fast, secure, and cheap to improve — and improvement work deserves its own clean runway.
The Restore Test, Run Properly
The restore test deserves its own procedure, because done wrong it proves nothing. The safe version: pick a quiet window, restore last night’s backup to a staging environment — never over production — and confirm three things in order: the front page loads, a protected page loads for an authenticated test user, and the newest piece of content exists. If all three pass, delete the staging copy and note the date in the run-log. If any fails, the backup job is the suspect, not the backup file — check the job’s logs before assuming the archive is corrupt. Thirty minutes, once a month, turns the most lied-about line on any dashboard into the one line you can swear to — and it is the only check on the whole list that pays for itself the first time it fails.
If you adopt only one habit from this list, adopt the restore test. Everything else on the checklist prevents problems; the restore test is the only item that proves your safety net is real before you need it.