- Monthly Updates: WP, Plugins & Themes*
- Daily Database & Weekly Files Backup
- Wordfence Security & Firewall
- Malware Scans
- 50% off Hack/Malware Removal
- Basic Speed Optimisation#
- Content Updates & Edits
- Technical Support via Email
- 30 Minutes Extra Support*
- Everything in Small WP Plan
- Staging Site: as/if required
- Help Desk Service for Staff
- Support Tickets
- Handle Hosting & Plugin Support Issues
- Uptime Monitoring
- Google Search Console Monitoring
- Monitoring AHREFS project
- Monthly Website Technical Audit
- 90 Minutes Extra Support*
- Everything in Small & Company Plans
- Weekly Updates: WP, Plugins & Themes*
- Staging Site: Live Update Testing
- Advanced Speed Optimisation#
- Twice Daily DB & Daily Files Backup
- Monitoring Search Rankings
- ROI Focus via Speed & Technical SEO
- Monthly AI Analysis of Audit Logs
- Monitoring Firewall logs for DDoS
- Revising Security Rules for DDoS
- 180 Minutes Extra Support*
Important Notes
- * Monthly payments are available but there may be an initial setup fee.
- # DDoS Mitigation Services – I can provide Cloudflare security rules implementation for “attack relief”, and caching rules implementation to improve load speed and reduce your origin server load.
- * WP Theme Updates: except if your theme is wildly out of date and no longer has developer support. In which case you may need a website redesign.
- * Monthly Technical Audit: “Website Auditor” software analysis of page content, load speed, and Google Search Console data to identify issues.
- # Speed optimisation: starts at basic page caching, extends to persistent object caching, opcache, asset cleanup, minimising unused CSS and Javascript, image optimisation and conversion etc…
- * Extra Support Time: for resolving any current issues, research, audits, analysis, or features.
We prioritize transactional uptime—ensuring your checkout works 100% of the time so you never miss a sale.
Most maintenance plans treat online shops like digital brochures. That’s a mistake that costs you money. If a brochure site goes down for an hour, nobody notices. If your WooCommerce store drops for 60 minutes, your revenue hits zero and your customer trust evaporates.
I run a “Checkout-Critical” operation. I don’t use automated scripts that blindly update plugins and cross their fingers. That’s how carts die while your “managed” host tells you everything looks fine.
The Staging Protocol
I prefer to NOT test on your live site. Ever. It is more sensible to use a staging environment to clone your store and break things there first.
I manually verify every update that touches your checkout. I’m not just looking for a 404 error; I’m checking that your API calls to Xero or MYOB are actually firing. As a 20-year veteran, I know the “stable” updates are often the ones that secretly kill custom shipping rules. I try to find those breaks before your customers do.
Performance is a Revenue Lever
Speed isn’t a vanity metric. Industry research, like the Deloitte “Milliseconds Matter” report, proves that site speed is a direct lever for revenue. When pages load faster, people buy more. It’s that simple.
Here is how the data breaks down:
| Metric | Business Impact |
| Mobile Speed | A 0.1s improvement can lift conversion rates by 8%. |
| User Engagement | Faster sites see a 5-10% increase in average order value. |
| Technical SEO | Improved Core Web Vitals directly correlate to better search rankings. |
Stop treating your shop like a hobby and start treating it like the engine room of your business. You get my direct oversight, not a junior assistant or a bot.
How much revenue is currently leaking out of your checkout process?
Recent benchmarks from 2024 through 2026 show that speed isn’t just a technical goal—it’s a financial one. If your site is slow, you’re essentially paying a tax on your own revenue.
The Cost of Slowness
- The 7% Drop: A single second of lag can slash your conversions by 7%.
- The 3-Second Cliff: If your load time slips from one second to three, your conversion rate can plummet by 20%.
- Mobile Abandonment: Over half of mobile visitors—53%—will bail if your page takes more than three seconds to appear.
The Speed Dividend
- The 0.1-Second Win: Improving your mobile speed by just a tenth of a second can lift retail conversions by over 8%.
- Higher Order Value: That same tiny speed boost often increases the average order value by 9.2%.
- The 3x Multiplier: Sites that hit the 1-second mark see conversion rates three times higher than those laggards taking five seconds.
Is your current host actually helping you hit these numbers, or are they just keeping the lights on?
If you want to know what slow loading actually costs you, the data is pretty blunt. There is more than one way to skin a cat, but ignoring your site speed is the fastest way to kill your margins.
How Load Time Hits Your Bottom Line
| Load Time | Conversion Impact | Bounce Rate |
| Under 1 Second | Peak Performance | ~7% |
| 2 Seconds | -5% to -7% | ~9% |
| 3 Seconds | -20% | ~13% |
| 5 Seconds | -35% or more | ~38% |
As my grandfather used to say, an ounce of prevention is better than a pound of cure. Most business owners wait until their traffic evaporates before checking their “engine room.” By the time you notice the slump, you’ve already paid a massive “slowness tax” to your competitors. Is your current setup hitting that sub-one-second mark, or are you just hoping for the best?
These numbers aren’t arbitrary; they’re tied to how our brains work. When a site responds in under a second, it feels instant. That keeps a customer in the “buying state” where they’re actually focused on your product.
Once you hit the 3-second mark, things fall apart:
- Trust vanishes: Users subconsciously link a slow site with poor security. If you can’t keep a page loading, they don’t trust you with their credit card.
- Focus drifts: People don’t just sit and wait; they switch tabs or check a notification. Once they leave your “flow,” they’re gone.
- The Cart Tax: A massive 87% of shoppers will dump a cart if the checkout feels glitchy or sluggish.
You’ve spent money getting them to the checkout. Are you really going to let a slow server kill the sale at the finish line?
E-commerce Case Studies & Security Incident Reports
If you are in a competitive niche with cut-thoat competitors, remember that DDoS-for-hire services typically cost just US$5 to $7 per hour. Meanwhile, the average business stands to lose around US$234,000 in downtime, recovery costs, and lost revenue.
Foreign attackers have control of multiple websites throughout NZ!
In February/March 2026, DDoS attacks are using NZ-based residential proxies to flood the New Zealand business websites with complex search queries.
- Residential Proxy “Spoofing”: A large volume of traffic was coming from NZ-based residential ISPs (like Spark and Voyager). This confirms that the botnet was able to heavily use hijacked NZ home internet connections to try and bypass the country-level filters usually applied in local NZ incidents. THAT IS A WAKEUP CALL…
Incident Report: The “Perfect Storm” Forensic Recovery and Hardening Case Study
- Site: Teaching Resources Shop
- Business Location: Tauranga, New Zealand
- Server Location: Fastcomet
- Dates: 14th – 17th February 2026
Author: Ben Kemp – Senior WooCommerce Support
G’day! Ben Kemp here from Website Maintenance Services NZ. We’ve just wrapped up a major forensic recovery and infrastructure hardening project for the membership platform at Top Teaching Tasks Members
Over the last four days, the site didn’t just have a “bad day”—it suffered a classic cascading failure. This was a scenario where a small application conflict creates a resource bottleneck, which then crashes the database and jams the background task runner. At the same time, whilst effecting repairs, we experienced an external bot attack by someone with an interest in damaging the business’s activities. This is not the first time it’s occurred, and the site owner is familiar with the need to activate “Under Attack” mode.
This report is designed to be an educational case study. I’ll walk you through exactly how we navigated this “perfect storm” to get the site back to peak health and onto a strict “database diet.”
Contents
- Incident Report: The “Perfect Storm” Forensic Recovery and Hardening Case Study.
- 1. Initial Crisis: The Digital Traffic Jam (Errors 524 & 522)
- The Advice from Fastcomet
- Our Remedy and Why.
- 2. Discovery of the 9.1 GB “I/O Bomb” (Error Log Bloat)
- What the error indicated?
- Our Remedy and Why.
- 3. Structural Damage: The Posts Table Crash.
- What the error indicated?
- Our Remedy and Why.
- 4. The Action Scheduler “Logjam”.
- What the error indicated.
- Our Remedy and Why.
- 5. Bot Attack Recognition and Staging Cleanup
- What the error indicated?
- Our Remedy and Why.
- 6. The PHP “Hard Reset” and Recovery Verification.
- What went wrong?.
- What the error indicated?
- Our Remedy and Why.
- 7. Modernizing the Architecture (InnoDB & HPOS)
- What went wrong?.
- Our Remedy and Why.
- 8. Final Challenge: Putting the Database on a Diet
- Current State.
- Completed “Diet” Actions.
- 9. Recovery Verification (TOP Output Analysis)
- Summary Checklist and Future Steps.
1. Initial Crisis: The Digital Traffic Jam (Errors 524 & 522)
What went wrong?
The owner and members reported that the site was completely inaccessible, showing Cloudflare error pages. Initially, it was a 524 error, which eventually worsened into a 522 error.
What the errors indicated
These codes aren’t random; they tell us exactly where the “conversation” between the visitor and the server broke down.
| Status Code | Meaning | Internal State |
| Error 524 | A Timeout Occurred | Cloudflare reached the server, but the server didn’t send data back within 100 seconds. It was “thinking” but stuck. |
| Error 522 | Connection Timed Out | The server was so overwhelmed it couldn’t even establish a basic TCP handshake to “pick up the phone” . |
The Advice from Fastcomet
The technicians insisted this was a “Cloudflare-side error” and told us to deactivate the proxy on the “A” record (switching from the “Orange Cloud” to “DNS Only”).
Our Remedy and Why
I disagreed and refused this risky advice because in my experience, disabling the proxy is a dangerous “symptom suppression” tactic. It would have removed the Cloudflare error page, but the visitor would have just seen a blank white screen with the Cloudflare error for two minutes. Most importantly, it would have exposed the origin server’s direct IP address to attackers, which is a massive security risk during a DDoS event.
As sure as God made little green apples, I sure as hell wasn’t going to reveal that origin server IP Address! This isn’t the first DDoS attack on this website, and last time (late 2025) we relocated the website from A2 Hosting to Fascomet while on Cloudflare. Specifically, to ensure that nobody could possibly know that IP address and target it directly.
What I have seen over the years is that the instant consequences of disabling the Cloudflare proxy is to transfer the full weight and drama of the entire DDoS attack onto the web server! That’s precisely not what’s needed when you’re trying to block an attack; it would be the dumbest move possible.
Instead, we turned on the Cloudflare “Under Attack” mode to slow things down a bit. That gave some breathing room while I got busy trying to determine what the methodology was behind the attack.
However, it became apparent that we were being hurt by multiple problems at once, from an attacker, from the legacy of previous developers who hadn’t tidied up, from errors overwhelming the error_log file, and from the massive “table locking” database still on MyISAM format instead of the more efficient InnoDB format.
2. Discovery of the 9.1 GB “I/O Bomb” (Error Log Bloat)
What went wrong?
While hunting through the website’s files for potential bottlenecks, I found a single text file – the error_log – that had grown to a staggering 9.1 GB.
What the error indicated
On shared hosting, a file this size is a disaster. Every time a member clicked a page, the server tried to append a new line to this file. Because it was so huge, the server’s disks were “thrashing” just trying to find the end of the file. This creates I/O Wait ($wa$), where the CPU sits idle doing nothing because it’s waiting for the slow hard drive to finish writing logs.
Our Remedy and Why
We had to stop the “bleeding” immediately:
- Immediate Deletion: We nuked the 9.1 GB log to give the disk immediate relief.
- Silencing the Debug: We found a conflict in WP Rocket (a feed_base property error in PHP 8) firing thousands of times per minute. We updated `wp-config.php` to stop these minor warnings from hitting the disk.
Code added to wp-config.php:
PHP
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);3. Structural Damage: The Posts Table Crash
What went wrong?
Even after the log was deleted, the site was “hanging.” The fresh log showed a critical error:
Table ‘posts’ is marked as crashed and should be repaired.
What the error indicated
The posts table is the “heart” of a WordPress site. Because the server was so overwhelmed by the 9GB log file, a database write was likely interrupted mid-sentence, leaving the table corrupted. Because the membership plans live in this table, the site couldn’t process permission checks, causing a total freeze.
Our Remedy and Why
We used phpMyAdmin to run a manual REPAIR and OPTIMIZE on posts.
- The Result: Table restored to “Status OK.”
- The Catch: One corrupted record was unrecoverable and discarded (418,420 rows down to 418,419).
4. The Action Scheduler “Logjam”
What went wrong?
Renewals still weren’t firing. We found a “Duplicate entry” error for key ‘PRIMARY’ in the wpaj_actionscheduler_actions table.
What the error indicated
The Action Scheduler is your website’s “alarm clock” for background tasks. The previous database crash scrambled the ID numbers. Every time WP Rocket or WooCommerce tried to set an “alarm” for a renewal, it failed because it tried to use an ID number that already existed.
Our Remedy and Why
We ran a “Hard Reset” on the background tasks by truncating (emptying) the four Action Scheduler tables. This cleared the jam and allowed the system to start fresh with a clean sequence of ID numbers.
5. Bot Attack Recognition and Staging Cleanup
What went wrong?
The site was stable only when Cloudflare’s “Under Attack” mode was ON. Turning it off brought back the 524 timeouts.
What the error indicated
This confirmed an external bot attack , . Fastcomet eventually acknowledged that a DDoS attack was in progress. We also discovered bots were hammering 5 old staging and backup subdomains sitting above the /public_html/ directory. This is a direct consequence of developer incompetence: creating staging sites in subdomains instead of subdirectories, and not “cleaning up” afterwards.
Our Remedy and Why
- Directory Purge: We deleted those five old directories to remove the metadata burden from the server.
- DNS Hardening: We deleted the old A-records, SPF, and DKIM records for those subdomains so traffic is blocked at the Cloudflare edge.
- WAF Rules: We created custom rules in Cloudflare to challenge any POST requests to the Cart, Checkout, login, xml-rpc, and WooCommerce Store API.
6. The PHP “Hard Reset” and Recovery Verification
What went wrong?
Even after fixing the database, our system monitors showed a PHP worker (PID 151338) hanging for over 6 minutes.
What the error indicated
On the Fastcoment shared hosting, we have a strict Entry Process (EP) limit of 20. If 20 old scripts are “stuck” in a zombie state from the previous crash, no new members can get in.
Our Remedy and Why
We performed a Hard Reset by toggling the PHP version in cPanel (8.3 to 8.2 and back). This forces the server to kill every active process for your account and start a clean pool.
7. Modernising the Architecture (InnoDB & HPOS)
What went wrong?
The store was using the MyISAM engine. MyISAM uses “Table-Level Locking”—meaning if one bot hits the cart, the entire posts table is locked for everyone else.
Our Remedy and Why
- InnoDB Conversion: We had Fastcomet convert all 139 tables to InnoDB. This engine uses “Row-Level Locking,” allowing the server to handle renewals and visitors simultaneously.
- HPOS Implementation: We have successfully enabled High-Performance Order Storage (HPOS). This moves our 11,000+ orders into optimised, dedicated tables, making queries up to 90% faster.
8. Final Challenge: Putting the Database on a Diet
Current State
Our database was 1.6 GB, and the wpaj_postmeta table has a staggering 4.5 million rows. This is why the admin dashboard felt “sticky”—every search had to sift through millions of old records.
Completed “Diet” Actions
- Trim Revisions: We added code to wp-config.php to limit WordPress to saving only the 5 most recent versions of any post.
- Code Added: define(‘WP_POST_REVISIONS’, 5).
- Preloader War Resolved: We disabled the Super Page Cache preloader as it was competing with WP Rocket for those 20 Entry Process slots.
- Manual Renewal Recovery: The site owner has now manually processed renewals for Nicxxx (#64xxx) and others who had the red question mark (lost “alarm clocks”). These are now back in the automated cycle.
9. Recovery Verification (TOP Output Analysis)
Looking at the terminal image from our final session, the server has fully recovered:
- Healthy Idle State: CPU is 87.4% idle.
- Disk Relief: our I/O Wait ($wa$) has dropped to a negligible 0.2%.
- Memory: We have 3.6 GB of free physical memory available.
Summary Checklist and Future Steps
- [x] 9.1GB Log Purged & Debugging Silenced
- [x] Posts Table Repaired & Optimised
- [x] Action Scheduler “Hard Reset”
- [x] Old Staging Folders & Dangling DNS Deleted
- [x] WAF Rules for Store API Created
- [x] InnoDB Conversion Completed
- [x] HPOS Synchronisation Completed
- [x] Manual Renewals (Nicxxx, etc.) Re-synced
- [x] Post Revisions Limited in wp-config.php
- [x ] Flipped HPOS Authoritative Switch (after initial 7-day dual-write test).
- [x] Used Advanced Database Cleaner PRO to purge orphaned metadata from the 11,000 old order rows.
Ben’s Summary: We’ve done the hard yards on the technical side. We’ve fixed the engine, reinforced the chassis, and built a massive (fire)wall at the front gate. The website is now in the best technical shape it’s been in for years!
Cheers,
Ben Kemp
Senior WooCommerce Support
Over the last two weeks of February 2026, I’ve been caught up in some very disturbing DDoS situations. One on my own websites, where a presumed competitor apparently thought it might be advantageous to have my website/s rendered inoperable.
The other attack targeted a client in Tauranga who operates two very busy websites selling educational resources. 10 days ago, website performance began to degrade, and it quickly became obvious that this was much more than the low-level Denial of Service attacks she had previously experienced, starting about 4 months ago.
It also became clear that this was now more than one person involved, and they were simultaneously trying to take down both websites using different tactics. Both sites were rendered almost unusable throughout Saturday, 28th March. We had them on Cloudflare, on “Under Attack” mode, and it took me hours to get the firewall Security Rules tight enough to slow the attacks, restart stalled server processes and restore some functionality.
The techniques used were very sophisticated, and as one line of attack failed, they promptly switched to a different tactic. I was running Cloudflare firewall log file extractions every 30 minutes throughout Saturday… Then, running the log files through Gemini AI for analysis, getting the Security Rules revised, and reloading them to Cloudflare. It took 14 hours to slow the attacks down and to get the websites working again.
These people had control of multiple websites throughout NZ. Attackers were using NZ-based residential proxies to flood the site with complex search queries.
- Residential Proxy “Spoofing”: A large volume of traffic was coming from NZ-based residential ISPs (like Spark and Voyager). This confirms that the botnet was able to heavily use hijacked NZ home internet connections to try to bypass the country-level filter we had applied. THAT IS A WAKEUP CALL…
By Sunday evening, we were back in full control of both websites, all functionality was restored, and zero impact was occurring from the attacks, which continue throughout today (Monday)…
The things that saved us were:
- Having Cloudflare already deployed results in better performance and resilience.
- One site had just been converted to the WooCommerce HPOS (High Performance Order System), which requires a database table format update to InnoDB. We got A2 Hosting to switch the other site to InnoDB while under fire. The DDoS attack had already broken one of the database tables, which needed tech support to repair and optimise it.
- Having Gemini AI and a set of well-tested Prompts saved and ready to deploy from my own battle earlier in the week
- And having premium-grade hosting – one site on A2 in Singapore, the other on a Fastcomet Cloud 3 VPS in Sydney.
On my own sites, the battle was brutal – but I certainly learned some valuable skills.
Future-proofing websites requires optimisation of the Cloudflare caching rules that now allow Edge caching:
– Where you have better control of WHAT gets cached, and if it’s pushed worldwide.
– Getting pages pushed out from the Singapore data centre and into the Auckland/Sydney/California/EU Cloudflare locations dramatically improves page delivery speed and further reduces the load on the origin server.
Cloudflare Firewall Security Rules should be preemptive:
Rather than waiting for an attack to begin, and then figuring out what to do, you should:
- Implement a fundamental set of Cloudflare Security Rules that cover all the “normal” attack formats. Then, if you suspect things are slowing down, you’ve got instant access to live firewall log reports to see what is going on.
- Harden the server to protect from direct attacks (shroud it so it can’t even be seen)
- Implement a set of high-performance Cloudflare Caching Rules so you get the ‘free’ load speed boost
- Ensure that your WordPress database is in the high-performance InnoDB format, which does “row-level” locking and multi-tasking. As distinct from the classic MyISAM format, in which every “write” action locks the table until completion, creating instant bottlenecks during a rapid-fire DDoS attack.
- If you use Woocommerce, ensure its running on HPOS.
But it may take you a week or more to regain control of your website during a high-intensity attack! And the emergency hourly rate will be brutal!
Cloudflare has a FREE plan – that’s what I used on both the above examples.
– Getting it all configured is obviously not a 5-minute process.
– But if ever “an ounce of prevention is worth a pound of cure” then this is it!
E-commerce-Specific Technical FAQ
I handle Core Web Vitals so you stay ahead in the Google rankings. This is about total peace of mind for high-traffic or Ecommerce shops. You get “Priority One” support and the kind of technical heavy lifting that keeps your site at peak performance.
The Cost: $599 Monthly plus $195 Setup Fee
- 1 Hour Priority Tech Support: You get direct help for updates or troubleshooting during the day.
- WooCommerce Optimisation: I focus on making sure your checkout is fast and your transactions work.
- Forensic Malware Protection: I monitor the site constantly and perform manual cleanups if anything looks suspicious.
I handle Core Web Vitals so you stay ahead in the Google rankings. This is about total peace of mind for high-traffic or Ecommerce shops. You get “Priority One” support and the kind of technical heavy lifting that keeps your site at peak performance.
The Cost: $599 Monthly plus $195 Setup Fee
- 1 Hour Priority Tech Support: You get direct help for updates or troubleshooting during the day.
- WooCommerce Optimisation: I focus on making sure your checkout is fast and your transactions actually work.
- Forensic Malware Protection: I monitor the site constantly and perform manual cleanups if anything looks suspicious.
You can let your site decline with automated tools, or you can have a 20-year veteran actually watching the code.
“An e-commerce site is a 24/7 storefront. I focus on the ‘checkout-critical’ technical details to ensure your shop stays fast and profitable.”
Ben Kemp
