Skip to main content
Published on October 18, 2026 Black Friday falls on Friday, November 27 this year. A traffic spike rarely breaks a healthy server. It exposes what was already fragile: a cache that is installed but serves nothing, a backup nobody has ever restored, a plugin that auto-updated itself at 3 a.m. on the day. The seven checks below belong to the weeks before the sale, not the day before. Each one gives the why, the how, and what a good result looks like. They apply to WordPress, WooCommerce, PrestaShop or a small application, on a VPS or on shared hosting.

1. Caching: check that it serves, not that it is installed

A traffic spike is mostly anonymous visitors looking at the same pages. If every one of those views runs PHP and queries the database, the server does the same work a thousand times over. Three layers matter:
  • the page cache: the full HTML page, served to logged-out visitors without touching PHP;
  • the object cache: SQL query results held in memory, typically in Redis, which speeds up what the page cache cannot serve;
  • the exclusions: what must never be cached.
Start with the exclusions. The WooCommerce documentation is explicit: the Cart, My Account and Checkout pages stay out of the cache, as do requests carrying the woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_ cookies. A cached cart is one customer’s basket shown to another. Then confirm the page cache actually answers, as an anonymous visitor:
Our web hosting plans include LiteSpeed. With the LiteSpeed Cache plugin on WordPress, the LiteSpeed documentation names the header to look for: X-LiteSpeed-Cache: hit from the second request onwards, and X-LiteSpeed-Cache-Control: no-cache on pages that are deliberately excluded.

Redis as an object cache, on a VPS

A cache with no ceiling ends up eating the RAM that PHP and the database need on the day of the spike. Set a limit and an eviction policy in /etc/redis/redis.conf:
On the WordPress side, the Redis Object Cache plugin is driven from WP-CLI:
After a few hours of normal traffic, look at the hit rate:
The Redis documentation gives the formula: keyspace_hits / (keyspace_hits + keyspace_misses). A low rate alongside many evicted_keys means the ceiling is too low.
A Redis reachable from the internet without a password is a way in, not a cache. See our RediShell advisory for the bind and ACL settings.
PrestaShop. Under Advanced Parameters > Performance, keep the Smarty cache enabled, do not use forced template compilation (it is meant for theme editing), and make sure debug mode is off. The PrestaShop 8 documentation advises testing the store after enabling the CCC JavaScript cache. Good result: a hit cache header on public pages, no-cache on cart and checkout, and a TTFB clearly lower on the second request than on the first.

2. A load test, before the day

You do not know how many visitors your server can take until you have measured it. The only good time to find out is before the sale. k6 is open source, runs in one command through Docker, and exits with an error code if your thresholds are not met. Run it from a different machine than the server under test, or you will be measuring your laptop more than your site.
According to the k6 metrics reference, http_req_waiting is the time spent waiting for the first byte: the TTFB. While the test runs, watch the server alongside it:
Only test your own site, and never the payment flow: you would create real orders and trip your payment provider’s fraud filters. On shared hosting, the server is shared with other customers: talk to support before running anything.
If the thresholds break, fix the cache first: it is almost always cheaper than a bigger server. If the server saturates even with a cache that serves, resize the instance from the console, and do it before the week of the sale. A resize is a change like any other: it goes through the snapshot in the next section. Good result: k6 exits with code 0 at your target traffic, with no swap and no 5xx in the logs.

3. A snapshot before every change, then the freeze

Every change before the sale (cache configuration, resizing, the last updates) starts with a snapshot from the console. It takes a minute and gives you a dated rollback point. For a VPS snapshot to capture a database in a consistent state, the QEMU guest agent must be running: it freezes the filesystem during the capture.
A snapshot is not a backup. It gets you back from a failed change, not through the loss of the server. That is what section 4 is for.
Then freeze. Apply every update before the sale and none during it: no deployments, no plugin or theme updates, no configuration changes. Keep WordPress core minor auto-updates on, though, since they carry the security fixes, as explained in our WordPress hardening guide.
Write down the one exception now: a critical, actively exploited flaw during the freeze. wp2shell was exploited within hours of disclosure. In that case: snapshot, patch, check the checkout flow. Nothing else. Good result: a snapshot taken after the last updates, the QEMU agent active, and an empty list from wp plugin auto-updates status --all --enabled-only during the sale.

4. Backups you have actually restored

A backup that has never been restored is an assumption. The 3-2-1 rule, as worded in the US-CERT paper published by CISA:
  • 3 copies of any important file: the original and two backups;
  • on 2 different media types;
  • with 1 stored offsite.
Applied to a site hosted with us: The snapshot does not count: it lives in the same place as the server. Then test restoring the database, the part that breaks most often:
Adjust the database name and table prefix to your installation. On PrestaShop, compare ps_orders. Good result: the counts match, the site comes up on the test environment, and you know how long a full restore takes. That number tells you how many sales you would lose on a Friday evening.

5. Monitor TTFB, not just uptime

A typical uptime probe is satisfied with a 200. A store that answers 200 in nine seconds is up for the probe, and closed for your customers. Measure TTFB (time to first byte). web.dev rates a TTFB of 0.8 s or less as good and anything above 1.8 s as poor, noting that this is a rough guide rather than a Core Web Vital. Start there, then adjust to your own measurements. Watch two URLs: a cached page, which measures the web server, and the cart, which is never cached and so measures PHP and the database. The cart is what slows down first.
If you prefer graphs, Uptime Kuma is part of the One Click Apps catalogue and charts the response time of every probe. Install it on a different server than the store: monitoring that goes down with the site warns nobody. Good result: a few days of measurements before the sale so you know your normal level, and a test alert received on the right channel, by the right person.

6. DNS: lower the TTL 48 h before any migration

The best DNS advice for Black Friday week: do not migrate. If you must move servers anyway, prepare the switch in advance. Resolvers keep a record cached for its full TTL. If your A record has a one-day TTL, some of your visitors will keep landing on the old server for up to a day after the change. So lower the TTL first, then wait at least the old duration before switching. Forty-eight hours cover the usual one-day TTLs with room to spare. Read the configured TTL straight from an authoritative server, not from your resolver’s cache:
If the old TTL is longer than 48 h, wait correspondingly longer. In your domain’s DNS zone in the console, the TTL field offers 5 minutes, which is 300 seconds. If the domain is linked to a web hosting plan, the zone is managed in cPanel. The page on pointing a domain at a VPS covers the records to write. After the switch, keep the old server online as long as its access log still receives requests, then raise the TTL again. Good result: dig against the authoritative server shows 300 at least 48 h before the switch.

7. Security under load: decided before, not during

Friday evening is not the time to find out how to ban an IP address. Everything below gets set up and tested now. Plugins up to date before the freeze.
fail2ban on SSH. Since Debian 12, rsyslog is no longer installed by default according to the release notes: there is no /var/log/auth.log, so the sshd jail has to read the systemd journal. The Debian 13 and Ubuntu 24.04 packages already do this; the Debian 12 one does not. Setting it in jail.local covers all three.
Rate-limit where it helps, and nowhere else. On WordPress, the login page is the usual target. The nginx hardening guide covers limit_req in detail. For wp-login.php:
The fastcgi_pass is not optional: without it, nginx would serve the PHP file as a static download. fail2ban then ships an nginx-limit-req filter, which reads the nginx error log and bans addresses that repeatedly exceed the limit:
The backend = auto line is not decoration: Ubuntu 24.04 points every jail at the systemd journal by default, while nginx writes its errors to a file.
Put no limit on your payment provider’s callback URLs, nor on /wp-json/ as a whole: a blocked payment webhook is a paid order stuck in “pending”. WooCommerce: throttle checkout attempts. If your store uses the Checkout block, WooCommerce offers checkout rate limiting under WooCommerce > Settings > Advanced > Features. According to the Store API documentation, it is off by default and, once enabled, caps checkout at 3 requests per 60 seconds. Place a test order after turning it on. The procedure, in writing. Who is on call, and how to ban an address by hand:
Do not switch on the console firewall in a hurry. As soon as the first rule is added, it blocks all traffic that is not explicitly allowed. If you want one, set it up well before the sale, with the SSH, HTTP and HTTPS rules. If something goes wrong, the KVM console remains available.
Good result: no plugin waiting for an update, both fail2ban jails active, a test order placed with WooCommerce rate limiting on, and a procedure someone other than you can follow.

What this actually buys you

None of this makes a server unbreakable. These checks move the work: away from Friday evening, when every minute costs sales, and into the weeks before, when a mistake costs nothing more than a snapshot rollback. If you only have time for two, run the load test and the restore. They are the two that expose what you assume is already handled. Questions about a server hosted with us? Our team is available from your client area.
Black Friday at OnetSolutions. From Friday, November 27, 2026 at 00:00 to Tuesday, December 1, 2026 at 23:59 (Paris time), a single offer on the first year of our VPS and web hosting plans on annual billing. New services only, once per customer. Renewal is at the normal annual price. How it works and the dates.