Websites - rescue, tuning and security
Server anomalies, slow pages or under attack? We find out why.
When a WordPress site keeps going down, restarting the server only buys a day. We read the server's own records, find the real cause, fix it with an undo plan for every change, and leave you a plain-English report of what was done.
$ checkup --read-the-logs out-of-memory freezes 22 in 4 weeks editor load time 25 to 55 s worst scanner burst 9,000 req / min scheduled tasks never ran $ checkup --fix --snapshot-first snapshot taken ok memory limits sized ok scanner limit in place ok page cache serving ok memory in use 1.6 GB to 1.0 GB
What we fix
Most struggling WordPress servers have more than one problem, and they feed each other. We look at all of them before changing anything.
Freezes and crashes
Servers that run out of memory and need a restart. We size the workers, limits and swap space to what the server can actually hold.
- Memory and worker limits
- Scheduled task pile-ups
Slow pages
Pages built from scratch on every visit, heavy images and bloated styles. We cache, compress and trim until pages arrive ready-made.
- Server page caching
- WebP images, lighter CSS
A slow editor
An editor that takes most of a minute to open usually means add-ons loading everything they own. We switch off what your pages never use.
- Plugin and widget audit
- Database write cleanup
Scanners and attacks
Bots that try thousands of passwords or hammer the server with requests. We limit them without getting in the way of real visitors or editors.
- Request rate limits
- Closed ports, hidden user lists
Security cleanup
Old admin tools, half-removed plugins and loose file permissions. We remove what should not be on a live site and close the doors left open.
- Unused plugin removal
- File editor and permissions
Updates gone wrong
An update that takes the site down, or a license that quietly stopped updates months ago. We roll back fast and set out the safe order to update.
- Rollback in minutes
- License and update plan
Two recent rescues
Both in the same week, on two different clients' servers. Names are left out; the numbers come straight from the servers' records.
22 freezes in four weeks, and an editor that took a minute to open
What the owner saw
The sites froze again and again and had to be restarted from the cloud console. Pages were slow, and the page editor took 25 to 55 seconds to open.
What we found
- The server could start more WordPress workers than its memory could hold, with no swap space to absorb a spike.
- One editor left open in a browser around the clock kept the server 50 to 70 percent busy.
- The job that runs WordPress's scheduled tasks had never run at all.
- One scanner sent over 9,000 requests in a single minute.
- About 2,900 leftover files from a certificate renewal that had been failing quietly since 2023.
What we changed
- Swap space, capped workers and a time limit on any single request.
- Page caching, compression and lighter WebP images on all four sites.
- One site's styling cut from about 75 KB to 4 KB per page.
- Unused editor widgets switched off, so the editor opens faster.
- 188 photos moved off Google Drive onto the server, and the sync plugin retired.
- A per-visitor request limit, closed ports and unused plugins removed.
A server that froze without leaving a trace
What the owner saw
The site and its marketing emails went down without warning. The server's error logs showed nothing, so every past freeze had gone unexplained.
What we found
- The freezes left no error because the server slowed to a crawl instead of crashing. Its performance recordings showed free memory falling from 2.36 GB to almost nothing in four minutes.
- The trigger that day was a scanner: 508 requests in under three minutes, each starting a new WordPress worker.
- On other days, the marketing system's scheduled jobs piled up the same way.
- The memory cache was allowed a quarter of the server and sat mostly in swap.
What we changed
- Swap space, a right-sized worker pool, and locks so scheduled jobs cannot overlap.
- A request limit for anonymous visitors that logged-in staff never hit.
- The cache capped at 256 MB, and 265 MB of interrupted save files cleared.
- An incompatible plugin update caught and rolled back within minutes, with the safe update order written down for the owner.
Every change in both rescues was preceded by a full server snapshot and has a written undo step.
How a rescue runs
The same discipline we use on production business systems, sized for a website.
Read the records
Server logs, memory and performance history, and traffic. We diagnose from evidence, not guesses.
Report first
A numbered list of findings, each with its cause, its fix and its risk, before anything changes.
Snapshot, then change
A full server snapshot and a written undo step come before every change you approve.
Fix the cause
Memory, caching, scheduled jobs, scanners, plugins. Not just another restart.
Check after a week
We come back after a week of real traffic to confirm the fixes held.
Hand it back
A plain-English report of what changed, what you will notice, and what could still be done.
Common questions
If yours is not here, ask. You will get a straight answer.
Do we have to move hosts?
No. We work on the server you have, whether it is on Google Cloud, AWS or elsewhere. If it is genuinely too small, we will say so and show you the evidence.
Will the site go down while you work?
Most changes are made live. Anything that needs a restart is scheduled with you for a quiet time.
Can you work on a site someone else built?
Yes. We review the site and the server first, report what we find, and change nothing without your approval.
What if a change causes a problem?
Every change has a snapshot and an undo step written before it is made, so we can put it back in minutes.
Let's look at your server