What a month of Drupal maintenance should actually check

Short answer: a month of Drupal support and maintenance should prove five things, not just report them. Every security advisory that touches your site was assessed and acted on. Updates went out on a schedule and were tested before they shipped. Each deploy really changed the live site. A backup was restored, not just taken. And you got all of it in writing. A green dashboard proves none of these on its own. Below is each check, with what it caught on our own sites.

Why isn't a green dashboard enough?

Because a dashboard reports what a tool believes, and tools are wrong in quiet ways. Two examples from our own estate:

• A pipeline that shipped nothing for a month. One of our own sites, Zero-Shot Games, served a stale image for a month because its deploy step was written to warn, not fail, when a secret was missing. Every run was green. We tell the story on its page.
• A cache purge that said "success" and evicted nothing. On 20 October 2026, Cloudflare's API answered "success": true to a purge on another of our sites, and the page stayed in the cache, as old as before. The site's cache rule matched only GET and HEAD requests, and a purge of a single address is a PURGE request. Since then we check a purge by requesting the page again and reading its cache headers.

Both were found by looking at the result instead of the report. That habit is what a maintenance month is for.

Were this month's security advisories assessed against your site?

The Drupal Security Team publishes advisories at drupal.org/security. Contributed modules have a release window every Wednesday, and core has one Wednesday a month, usually the third, between 16:00 and 22:00 UTC. A highly critical issue can come outside the window.

Assessing means asking, for each advisory, whether the site runs that module at an affected version. Then it gets one of three written answers: applied; mitigated until it can be applied; or not affected, and why. "Applied" needs its own definition, which we give in what "applied" should mean. The month should also cover the advisories Drupal does not publish: those for PHP itself and for the Composer libraries under Drupal.

Did updates go out on a schedule, and were they tested first?

On our own sites, the schedule lives in the code, not in someone's memory:

• On every push and every Monday, a composer audit checks the production dependencies. On a push, a known advisory blocks the build.
• Every Monday, a pull request brings in what our shared starter fixed for every site. It is audited and tested on a fresh install before it is proposed.
• Every Monday, an OWASP ZAP baseline scan reads the live site. It is passive: it reads pages and sends no attack. It first ran on 26 October 2026.

Two lessons sit inside that list. First, the ZAP scan never fails its run, so it is only worth something if a person reads the report. The monthly note is where that happens. Second, a schedule only helps if what it updates still receives updates. Our image's PHP 8.3 base had stopped at PHP 8.3.29 in January 2026, so rebuilding changed nothing. When PHP fixed two critical flaws on 21 October 2026, we moved the image to PHP 8.4 on 26 October.

One more check takes a minute: do Drupal's own update notices reach anybody? On 20 October 2026 we found four of our sites sending them to a placeholder address. Nobody was receiving them. The sites now take that address from each server's settings.

Did every deploy actually reach the live site?

Each gate in a pipeline proves one thing, and not the next one. On our sites:

• the dependency audit proves that nothing shipped carries a known advisory;
• the image build proves that the code installs;
• the deploy proves that a new image is running and that drush deploy ran;
• the health gate proves that the home page answers HTTP 200, with at least 5,000 bytes and no PHP fatal error.

None of them proves that the change you asked for is on the page. So a maintenance month does three more things:

• It reads which steps of each run actually ran, not the colour of the run. A skipped deploy can still leave a green run.
• It opens the changed page on the live site.
• It reads the cache headers after a purge, where a cache sits in front.

A push that adds or removes modules is rehearsed first, on a copy filled from production. Afterwards its configuration must show no differences.

Was a backup restored, not just taken?

A backup nobody has restored is a rumour. On 20 August 2026 we restored a nightly dump of one of our sites, and it showed that none of the dumps taken until then could be restored. The import ran clean, the blog came back empty, and there was no error: the dump had left out the revision tables Drupal needs to load content. We fixed it that day. On 18 September 2026, the first full drill restored the whole server from a snapshot, with every database loaded and the content counts matching production.

Our sites back up the database and files every night and keep a copy off the server, so at most a day of content is at risk. Our own procedure calls for a full restore every month. The check that counts is that content loads from the restored copy, not that the backup log says "done".

Did you get it in writing?

At the end of the month you should get a short note. It says:

• what changed (updates, fixes, deploys), each with its commit;
• which advisories were assessed, and what was decided for each;
• which deploys were checked on the live site, and how;
• which backup was restored, and what was checked;
• what the scan found;
• what is due next month, such as Drupal 10's end of life on 9 December 2026.

The note is also documentation. Whoever looks after the site after us can read it, without asking us.

What shouldn't a maintenance plan promise?

Several Drupal providers, in Colombia and abroad, publish monthly support plans priced by included hours and response time. When you compare them, compare what each plan checks and proves, not only the hours.

Here is what we don't promise. Today the engineer is our founder, so support runs in business hours on Colombian time (UTC-5), with no 24/7 on-call. When an advisory touches your site, we start on it the same business day. That is a term of the engagement, not a measured record. Hosting stays yours. Plan prices come after we have read your site. The one fixed price is an hour of the founder's time: USD 75.

To find out what your site's month checks today, write to us or ask the concierge on the home page. Our offer explains how we take on a site.