Release runbook · Beginner · 20 minutes per cycle
How to update WordPress safely — Treat Every Update Like a Deploy
The update itself takes four seconds; what you actually need is a way to tell, afterwards, whether anything got slower or quietly stopped working.
The short answer
Run updates as a release with a rollback, an order and a verification pass: snapshot first, update plugins then themes then core, rehearse anything load-bearing on a staging clone, and finish by re-measuring the two numbers you took beforehand. Our WordPress plans bundle staging sites precisely so the rehearsal costs nothing but ten minutes.
The order matters because dependencies point downwards, the snapshot matters because it turns a bad release into an undo, and the measurement matters because the update that breaks nothing visible can still add 300 ms to every request.
By the HostingFast team · Reviewed 24 August 2026
Beginner
Assumed skill
Quick
Time per cycle
5
Stages in the runbook
24/7
Cover, every day
This is written for someone who ships changes rather than someone who avoids them. Automatic updates are a tool here, not a moral position — the guide says which layer to hand over and which to keep in your own hands.
Before the first click, take two readings you can compare against later: time to first byte on a cached page, and the query count on your busiest template from Query Monitor. Everything after this is a diff against those two figures.
Snapshot, because rollback is the whole safety model
One manual backup taken immediately before the run converts every update from a bet into a reversible action. Name it after the change, not the date — 'pre-woo-9' is findable at eight on a Friday evening in a way that 'backup-3' never is.
Everything else in this runbook is sequencing and attention. This step is the part that means a bad release costs you eleven minutes rather than a weekend, and it is the step people skip precisely when they most need it.
The order, and what the changelog is telling you
Plugins, then themes, then core. Read the changelog on anything significant and check the 'tested up to' value: a plugin declaring compatibility two WordPress versions behind yours is publishing advance notice that nobody is maintaining it.
Watch the PHP requirement in the same pass. A plugin release that quietly raises its minimum PHP version is the most common reason an update succeeds on one site and throws a fatal error on the one still running an older interpreter.
Rehearse the load-bearing releases on a clone
Major version jumps, page-builder releases and WooCommerce updates get a staging pass. Push the update to the clone, click the checkout or the membership flow, then re-run PageSpeed Insights against the same URL you baselined. Ten minutes on staging buys certainty that no amount of reading the changelog can.
For the low-risk layer — minor core releases, small utility plugins — automation is genuinely the better answer. Selective automation beats both extremes: everything automatic, and nothing ever.
Verify in numbers, not in vibes
Afterwards, walk the homepage, one deep page, a contact form and checkout if you have one. Then compare your two readings. If a cached page has drifted from under 200 ms towards 600 ms, something in that batch added work to every request, and Query Monitor will name it in one look.
Two minutes of clicking plus one re-measurement catches the quiet breakage that otherwise hides for a month — the form that stopped emailing, the plugin now firing an uncached query on every page load.
Where the rehearsal is already included
Tutorials written against imaginary hosting rot fast. This one was written against the real thing: the same panel, the same installer and the same defaults sitting in your account right now.
Backups run daily on every plan, and restoring a file or a database is a single click in the panel rather than a support ticket.
- Staging environments for testing changes before they ship
- WordPress Toolkit, with updates handled for you
- Per-site PHP version switching from the control panel
- Human support on duty every hour of every day
Why HostingFast
Standard on every plan
A rollback before a risk
Every run starts with a named snapshot, so the worst outcome is eleven minutes lost rather than an evening.
Dependency order, explained
Plugins before themes before core, with the reason stated — not a ritual you follow because a forum post said so.
Compatibility read properly
'Tested up to' and the minimum PHP version are the two fields that actually predict a fatal error.
Rehearsal on a real clone
Load-bearing releases go to staging first, which the WordPress plans include, so the trial costs ten minutes.
Verified in numbers
You take TTFB and a query count before, and compare them after, so a silent regression cannot pass as success.
Scoped honestly
Running updates this way is a beginner-level job — about 20 minutes per cycle once the habit is in place.
Quick Start
From order to online
- 1
Take the two baseline readings
Time to first byte on a cached page with `curl -s -o /dev/null -w '%{time_starttransfer}'`, and the query count on your busiest template from Query Monitor. Thirty seconds now is what makes the after-check meaningful.
- 2
Snapshot and name it after the change
A manual backup labelled for the update you are about to run. Findable in a hurry, unlike a timestamp, and it is the only reason this whole procedure is reversible.
- 3
Update plugins, themes, then core
Dependencies point downwards, so work in that order. Check 'tested up to' and the minimum PHP version on anything significant before you click, not after the fatal error.
- 4
Send the risky ones to staging first
Major versions, page builders and WooCommerce releases get a clone run: apply, click the checkout, re-run PageSpeed Insights on the URL you baselined. Our WordPress plans include the staging sites for exactly this.
- 5
Re-measure, then automate the boring layer
Compare TTFB and query count against your baseline before you call it done. Then let minor core releases and low-risk plugins self-update, keeping manual control of the load-bearing few.
Built In
Loaded onto every plan
- Staging environments for testing changes before they ship
- WordPress Toolkit, with updates handled for you
- Per-site PHP version switching from the control panel
- Daily backups, with self-service restores you run from the panel
- SSH, Git and Composer on the developer-focused plans
- LiteSpeed caching built into the server rather than patched in by plugin
- WordPress and 400+ other applications installed in one click
- Human support on duty every hour of every day
- In-place account upgrades — no migration when you change plan
- A renewal price identical to the price you signed up at
Frequently Asked
What people ask us most often
Which updates genuinely deserve a staging rehearsal?
Anything that can take money or take the site down: major core versions, page builders, WooCommerce, membership and caching plugins. A minor release of a contact-form plugin does not. The test is not how big the version number jump looks but how much of the page depends on that code path.
How do I tell whether an update made the site slower?
By comparing, which means measuring first. Cached TTFB on one URL and a query count from Query Monitor on your heaviest template are enough. If cached HTML drifts from under 200 ms towards 600 ms after a batch, something in it added work to every single request — bisect the batch on staging rather than guessing.
What is the refund position if a plan turns out to be wrong for me?
Thirty days on shared, business, WordPress and WooCommerce hosting; seven on reseller. VPS and dedicated servers are built to order the moment payment lands, so they sit outside it, as do domain registrations, where the registry charges the instant the name is secured. Inside the window, one request returns your hosting fee.
What uptime do you aim at, and what happens in a bad month?
99.9% is the target, monitored around the clock, and we call it a target deliberately rather than dressing it up as a contractual SLA. If a month falls short because of a fault on our side, our terms entitle you to a pro-rated credit — ask and we apply it. Hardware and network faults usually surface in platform monitoring before the first customer notices.
Keep reading
How to Fix the WordPress White Screen
The blank page is a suppressed fatal error — how to get the message back on screen and bisect to the cause — intermediate, roughly 20–40 minutes.
How to Transfer a Domain
Move a name between registrars with the zone and the mail flow untouched — beginner, about 15 minutes of work and up to 5 days for the transfer to land.
Best Joomla vs WordPress
The same decision as a buying guide: which specifications move the numbers, which are marketing, and the plan we would sign.
WordPress Hosting
WordPress on LiteSpeed and NVMe, with staging clones and daily backups included.
Magento Hosting
Plans with the memory ceiling and PHP headroom Magento genuinely needs.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Ship changes with a rollback behind them.
Staging clones, daily backups, WordPress Toolkit and free SSL on every plan — with renewals billed at the rate you started on.
View WordPress Hosting plans