---
title: "What A WordPress Maintenance Month Actually Contains, Hour By Hour"
url: https://hostmy.blog/wordpress-maintenance-service/
date: 2026-09-08
modified: 2026-09-03
lang: en
author: "Aditya Sharma"
description: "A worked example of a maintenance month, itemised, so you can judge what you are paying for."
categories:
  - "WordPress"
image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1845-1024x538.jpg
word_count: 1546
---

# What A WordPress Maintenance Month Actually Contains, Hour By Hour

A maintenance month on a typical client blog costs us about two hours of labour. Roughly a hundred minutes of that is the part with any judgement in it. Everything else is machinery.

That ratio is why the industry sells maintenance badly. The pitch is always a list of tasks, because tasks are easy to put on a pricing page. The value is in the roughly a hundred minutes, and the roughly a hundred minutes is hard to describe until it has happened to you.

So here is a month laid out in full, on a blog of the shape we usually take on. Picture a food publication, several hundred posts, tens of thousands of sessions a month, WooCommerce disabled, one page builder, around thirty active plugins. Whether all thirty of those deserve to stay is [a separate call about which plugins earn their place](/wordpress-plugin-bloat/), and it is not part of this month. Read it as a worked example of where the time goes, not as one particular invoice.

## The month, itemised

| Task | Time | Automated or human |
| ---- | ---- | ------------------ |
| Core, plugin, theme updates across four batches | 38 min | Human review, automated apply |
| Post update visual check on 6 key templates | 22 min | Human |
| Backup verification, one full test restore | 15 min | Automated, human confirms |
| Uptime and response time review | 6 min | Automated, human reads |
| PHP error log triage | 18 min | Human |
| 404 and redirect review | 12 min | Human |
| Security scan review and one false positive dismissed | 9 min | Automated, human reads |
| Database cleanup, transients and revisions | 4 min | Automated |
| One actual incident, diagnosed and fixed | 34 min | Human |
| Monthly report written | 11 min | Human |

Total, two hours forty nine minutes. That was a slightly heavier month than average because of the incident. A quiet month is closer to ninety minutes.

Notice what dominates. The incident and the error log triage together are nearly an hour. Those are the two lines that no automation replaces, and they are the two lines that never appear on a maintenance pricing page.

## Updates are the smallest real part of the job

Everybody sells updates. Updates are close to solved.

We batch them deliberately rather than applying everything at once, which sounds fussy until the first time a batch breaks something. Four batches, in this order:

- Security releases, immediately, no waiting.

- Minor plugin versions, weekly, on staging first for anything that touches output.

- Major plugin versions, one at a time, staging, click through, then production.

- Core minor releases, within a few days. Core majors, after about two weeks unless there is a security reason.

The reason for one major at a time is diagnostic, not cautious. If you push nine updates together and the site breaks, you have nine suspects and no way to bisect quickly. Push them one at a time and the suspect is obvious.

That discipline costs maybe fifteen extra minutes a month. It has saved us several hours of guessing.

## What the incident actually was

Mid month, average server response time on the blog drifted from about 320ms to 900ms. No alerts fired, because nothing was down. The uptime monitor was perfectly happy.

The 900ms was visible only because we look at the response time graph, not just the up or down state, which is most of the difference between [signal and noise in site monitoring](/wordpress-monitoring/).

Cause: a plugin feature that wrote a row to a custom table on every post view, with no index on the column it then queried. A fortnight of traffic is enough to put hundreds of thousands of rows in a table like that, and every page load runs an unindexed scan across all of them.

The fix was to disable that specific feature and truncate the table. Which tables grow like that, and which ones to leave alone, is [its own piece of database housekeeping](/wordpress-database-maintenance/). Ten minutes. Finding it took the other twenty four, most of that spent in Query Monitor on a staging clone with production data.

Nobody complained. No visitor filed a ticket saying the site felt sluggish. That is the whole point of the roughly a hundred minutes. By the time somebody complains, the problem has been there for a month. Most of [what fails on a site nobody is watching](/what-breaks-when-nobody-is-watching/) fails exactly like that, quietly and without an alert.

## The boring check that finds the most: the 404 log

Nobody sells 404 monitoring. It is the most consistently useful check we run.

On the blogs we look after, a spike in 404s has told us, in order of frequency:

- Somebody edited a post slug in the WordPress editor and did not set a redirect. Traffic to that URL just stops.

- A plugin update changed an asset path, and a stylesheet is now 404ing on every page. The site looks fine on the editor's cached browser and broken to everyone else.

- Images from a 2019 media library import are missing entirely, which nobody noticed because the posts they sit in get 40 visits a month.

- A scraper is walking a URL pattern that does not exist, which is harmless but tells you somebody is paying attention to you.

Twelve minutes a month. It catches things that cost real traffic. Ask any maintenance provider whether they look at 404s and watch how they answer.

## The tools worth being wary of

It is common to see a well known all in one security plugin on every site we onboarded. It has a good reputation and a reasonable free tier.

We stopped, for two reasons.

First, its firewall module runs before WordPress loads by way of an `auto_prepend_file` in the PHP configuration. That is a legitimate design. It also means an incomplete uninstall leaves the prepend directive behind, pointing at a file that no longer exists, and the site fatals on every request. A fresh copy of a site with no security plugin on it, throwing a PHP fatal about a file that does not exist, is a genuinely confusing thing to debug under time pressure.

Second, and more importantly, it produced a lot of alerts that were not findings. Alert volume that high trains you to ignore alerts, and an ignored alert channel is worse than no alert channel.

What we run now is deliberately less, closer to [security that works with the host rather than against it](/wordpress-security/): server level rate limiting, a login lockout with a low threshold, file integrity monitoring for core and plugin files, and disabled file editing in the admin. Fewer moving parts inside PHP, fewer alerts, and every alert is worth reading.

That is not a claim that the plugin is bad. It is a claim that we were using the wrong tool for a fleet of sites we do not want to babysit individually.

## What a maintenance plan cannot do for you

Being clear about this saves everybody a difficult conversation later.

Maintenance does not make a slow site fast. Updates and cleanups do not touch the things that actually control page load, which we went through in [the changes that actually moved page load](/wordpress-speed-optimization/). If your theme ships 400KB of CSS, no amount of monthly care changes that number.

Maintenance does not stop you being hacked. It reduces the surface and shortens the time to detection. Those are meaningful and they are not a guarantee, and anybody selling you a guarantee there is selling you something they cannot deliver.

Maintenance does not grow your traffic. Two things sit adjacent to it. Keeping technical SEO plumbing intact, meaning redirects, canonical tags, sitemaps and structured data surviving updates, is a maintenance job. Deciding what to publish is not.

One item that has moved onto our onboarding list is AI crawler access, because a growing share of the referrals we see now come from assistants rather than search results pages. We use [RankReady](https://wordpress.org/plugins/rankready-ai-llm-seo/) for that, a free WordPress AI SEO plugin that runs alongside Rank Math, Yoast, AIOSEO or SEOPress without conflicting with any of them. Setup is about five minutes and it handles llms.txt, Markdown endpoints and crawler rules. It sits in the same category as the redirect check: plumbing that only shows up when it is missing.

## What to ask before you hire anybody

Four questions. The answers are more informative than any feature list.

**When did you last restore one of your clients' sites from a backup, and what went wrong?** A specific answer means they actually test. Read [backups, and the difference between having one and being able to use one](/wordpress-backup/) for why this is the question we care about most.

**What is your process when an update breaks a site?** Listen for whether they have a rollback path or whether the answer is that they fix forward under pressure.

**Do you monitor response time or only uptime?** Most monitor uptime only. Uptime misses the slow drift that ruins a site quietly.

**What will you tell me when nothing happened?** A provider who sends a monthly report saying everything was fine is being honest. A provider whose report is padded with invented findings is training you to stop reading it.

If you would rather hand this over than run it, that is what our care plans are. Say so and we will quote it. If you would rather run it yourself, everything above is the actual list, and none of it is secret.

The question that decides it: when your site last slowed down by half without going offline, how long was it before somebody noticed?