I keep seeing the same invoice: a monthly website maintenance fee for a four-page brochure site. Too often that invoice is for doing nothing, and the real maintenance cost of a site like that is close to zero.
I have watched agencies and freelancers run this the same way. Someone builds a WordPress marketing site, hands it over, and attaches a retainer. The promised scope includes core updates, plugin patches, cloud backups, and security monitoring. In practice nobody logs into the site for months. Updates run automatically, or someone bulk-clicks them once a quarter without regression testing. When something breaks, the client notices first.
I will not sell that. It turns routine software hygiene into a tax on a non-technical owner and does not buy operational safety.
I also will not pretend every maintenance contract is an upsell. When a system takes payments, syncs inventory with an ERP, processes recurring charges, or is the main sales channel, I want a real operations retainer. Downtime there costs money.
What I charge for depends on architecture and risk. I separate automated software updates from operational responsibility. Those are different jobs.
Why I don’t sell a monthly update retainer
A standard informational site does not need hours of manual developer work every month.
Modern hosts and CMS platforms already handle minor updates. WordPress has supported background core updates for years, and some managed WordPress hosts and paid add-ons run sandbox-tested plugin updates with visual regression checks. With a fully static build and no serverless functions, as I wrote in Astro + AI vs WordPress for simple content sites, the server-side attack surface all but disappears. A static site on Cloudflare Pages has no database to corrupt, no PHP runtime to exploit, and no plugins to patch.
Automation does not remove the work entirely. For a simple WordPress site I budget about an hour a month, sometimes two or three: reviewing major plugin updates that need a decision rather than a click, checking that the host is not retiring the PHP version the site runs on, confirming the contact form still delivers mail, and scanning the update log. A bulk management panel shortens that hour. It does not delete it.
I will not price that hour as a full monitoring retainer, or sell “Update All” clicks as security monitoring. That is a convenience fee dressed up as insurance.
Worse, clicking update without automated end-to-end tests does not prevent downtime. In an unmonitored retainer, updates often go out blindly. If a plugin conflict breaks the contact form or mangles the mobile layout, the site stays broken until a visitor complains. If a client pays me for maintenance and still has to act as the primary tester, I have failed the job.
If a site rarely changes, does not take payments, and is informational, the fee should match that review hour, not a full operations package. My architectural answer is to simplify the stack, turn on automated backups and updates, and bill developer time when there is a real change to make.
I charge for maintenance when downtime costs money
Maintenance becomes mandatory the moment downtime, data corruption, or a broken workflow destroys revenue.
Take a WooCommerce store with custom B2B pricing, automated stock feeds, and payment webhooks, the kind of setup I walked through in WooCommerce B2B: plugin sprawl vs owned integration. There, an update is never “just an update.”
A minor release of a payment gateway plugin can change webhook payload handling, so orders sit in “Pending Payment” while money leaves customer accounts. A WooCommerce core update can deprecate a filter used by an ERP sync and silently stop stock from moving. An unindexed query from an add-on can saturate the database or create lock contention at peak traffic.
On a transactional system I treat maintenance as four operational layers:
1. Business process integrity
Checking that the homepage returns HTTP 200 is trivial. I want to know whether the critical flows actually complete:
- Do test checkouts succeed through every active payment gateway?
- Are transactional emails passing DKIM/SPF and reaching inboxes?
- Did the night-time stock import finish without skipping SKUs?
- Are Action Scheduler queues running without timeouts?
2. Staging-first deployments
Production is not the test bed. Every dependency update goes through staging, smoke-tests cart and checkout, and only then reaches live traffic.
3. Log auditing and anomaly detection
Bugs rarely start with a crash. They start as PHP warnings filling the disk, rate-limit errors from an external API, or query times creeping up. I want error logs and slow-query logs read before that becomes an outage the customer can see.
4. Recovery time and data-loss guarantees (RTO and RPO)
Offsite backups are useless until someone has restored them. Real maintenance includes recovery drills: can a corrupted database or a compromised server come back to a known-good state inside an agreed window?
On an active store or application, I am selling risk reduction and a guaranteed response, not plugin updates.
Three models I use for website maintenance
I structure the work around one of three models. Anything fuzzier turns into a retainer for clicking buttons.
| Maintenance Model | Best Suited For | What You Actually Pay For | Typical Pricing Structure |
|---|---|---|---|
| Zero-Maintenance Architecture | Brochure sites, landing pages, static blogs | Upfront architecture (SSG/Astro), zero recurring software maintenance | $0/mo maintenance (pay ad-hoc per task) |
| Automated Hygiene + Incident Retainer | Standard business sites with forms, active blogs | Automated backups, uptime monitoring, monthly hygiene review, on-demand hourly pool | Low fixed tier or pure on-demand |
| Full Operations & SLA Retainer | E-commerce, B2B portals, custom integrations | Active flow monitoring, staging test pipelines, log audits, guaranteed SLA | Fixed monthly retainer scaled to the SLA |
Model 1: Zero-maintenance architecture
If the site’s job is to confirm the business exists, answer repeated questions, and take enquiries, as I laid out in Business Website Readiness: A Practical Decision Test, I would rather build on a stack that does not need a monthly patch cycle.
Astro, Pages CMS, or flat HTML on an edge host means no database to patch, no PHP to upgrade, and no plugins to manage. Recurring software maintenance is $0 a month. Hosting and domain still cost money. When content or design needs to change, I bill a scoped task.
Model 2: Automated hygiene with on-demand support
For a WordPress site that needs a dynamic backend because content changes often, I will not charge for clicking updates by hand.
The setup is managed WordPress hosting with automated daily backups, automatic patching, and third-party uptime monitoring (UptimeRobot or Better Stack). I charge at most a small fee for the monthly hygiene review. Plugin conflicts, new features, and other work are billed at an agreed hourly rate with a defined response window.
Model 3: Operational SLA and active monitoring
For stores, client portals, and systems the business cannot afford to have down, a high-touch retainer is justified. I will not pretend otherwise.
The contract has to specify:
- Guaranteed response time (SLA): critical production outages in 1 to 2 hours; non-critical bugs within 1 business day.
- Staging verification: no updates applied directly to production.
- Synthetic transaction monitoring: scheduled sandbox checkouts or low-value voided authorizations, so we know the payment gateways still work.
- Dedicated developer time: a set number of hours each month for performance work, indexing, and dependency refactoring.
Four questions I want answered before anyone signs
Before I sign a retainer, or before a client signs one with someone else, I want four answers:
-
“What happens in a quiet month, when nothing breaks?” If the answer is only “we keep your plugins up to date,” you are paying for a script. If it includes log reviews, staging tests, performance checks, or hours that roll over, the retainer has substance.
-
“How do you test that the site still works after an update?” If testing means opening the homepage, critical flows are unprotected. For a transactional site I want automated smoke tests, or a written QA checklist covering forms, checkout, and logins.
-
“What is the guaranteed response if the site goes down on a weekend?” A contract without an SLA is not an emergency service. If the answer is “best effort,” I would not pay an enterprise fee for it.
-
“Can this site be built so that monthly maintenance is unnecessary?” For a mostly informational site, an honest partner will show a static or headless option that removes the patch cycle, instead of defaulting to a CMS that needs perpetual care.
I charge for the work that protects revenue: monitoring critical flows, testing updates on staging, and a guaranteed response when something breaks anyway. I do not charge for button-clicking that software already handles.