WooCommerce sale readiness checklist: Black Friday or any big sale

A WooCommerce store fails on a sale day for a short list of reasons: an update nobody tested, a payment method nobody tried, a cart or checkout page served from a cache, the limits of the hosting plan, and emails that never arrive. Each one can be checked before the day. This checklist starts four weeks ahead and ends the day after. It uses Black Friday as the example and works for any launch or seasonal peak.

Count the weeks back from the first day of your sale. With less than four weeks, do the phases in the same order, faster, and keep the test orders.

Four weeks before: what takes time

• Write down the dates. The first and last day of the sale, the day the freeze on updates starts (two weeks before the first day) and the day it ends (the day after the last).
• Ask your host what the plan's limits are. The questions are below. An answer, or a move to a larger plan, can take days.
• Restore a backup once. Restore the newest full backup to a staging copy, never over the live store. WordPress's documentation says a full restore needs both the database and the files. Then find the most recent order in the restored copy. WooCommerce keeps orders in the database, so the gap between that order and now is what a restore would cost you. See how to schedule automatic WordPress backups.
• Make a staging copy, or refresh the one you have. Every test below runs on it. It holds your customers' data, so keep it private: how to set up a WordPress staging site.
• Apply every update that is waiting, on the staging copy first. That leaves two weeks for a fault to show before the last round. The method is under "Before any update" in how to maintain a WooCommerce store.
• Decide who is on call. One person who decides and one who can repair. If the second is a developer or an agency, ask now whether they can be reached on the day, and get the answer in writing.

What to ask the host

WooCommerce's caching guide says Cart, My Account and Checkout have to stay dynamic, because they show what belongs to one customer. So every shopper on those pages needs PHP to run on the server, and a plan caps how many requests PHP serves at once. The PHP manual documents that cap as pm.max_children. Hosts sell it under names of their own.

Ask in writing and keep the reply:

• How many requests can PHP handle at once on this plan? Does the next one wait, or get an error?
• Is there a limit on visits, bandwidth, processor time or memory? When it is reached, is the store slowed, shown an error page, suspended or charged more?
• Can the plan be raised for the week of the sale, and how long does the change take?
• How do I reach support on the day, including outside office hours?
• Do you apply updates to WordPress or plugins yourselves, and can that be paused?

A reached limit can show as a 503 Service Unavailable error that comes and goes. To see what the server gives the store today, go to WooCommerce, then Status, and read "WordPress memory limit", "PHP version" and "PHP time limit". WooCommerce's server recommendations ask for a WordPress memory limit of 256 MB or greater.

Two weeks before: the last update, then test everything

A test is worth something only while nothing changes after it. So this phase opens with the freeze.

Start the freeze

• Finish the last update today, on the staging copy first.
• Stop automatic updates for plugins and themes. Go to Plugins. In the "Automatic Updates" column, select "Disable auto-updates" for each plugin that has them on. Themes are switched one at a time, from the theme's details under Appearance. WordPress's documentation says auto-updates run twice a day by default, so a plugin left on can change at any hour of the sale.
• Leave WordPress's own maintenance and security releases on. WordPress's documentation strongly discourages disabling them.
• Tell everyone who can change the store: a colleague, a developer, an agency. No updates, no new plugins, no new cache or speed settings and no theme edits until the day after the sale.
• Keep one exception: a security fix. WooCommerce's update guide says a release with a security fix should be applied sooner than your schedule, and that its Advisories page and changelog flag such releases. Apply it on staging, place a test order there, then apply it to the live store at its quietest hour.

Place a full order through every payment method

Test mode proves the code. It does not prove that the live keys and your account with the provider are in order. Check those on the live store without a card: each gateway's settings show a live connection with test mode off, the most recent real order paid by each method reached "Processing", and the provider's dashboard shows no notice on your account.

Schedule and test the sale prices and coupons

• Schedule each sale price. Go to Products, open the product, and in Product data, under General, enter the "Sale price". Select "Schedule" and fill in "Sale price dates". WooCommerce's note on the field says the sale starts at 00:00:00 of the "From" date and ends at 23:59:59 of the "To" date, by the store's clock: the "Timezone" under Settings, then General. On a variable product each variation has its own price, and the bulk actions under Variations include "Set scheduled sale dates".
• Create the coupon under Marketing, then Coupons. Coupons work only while "Enable the use of coupon codes" is ticked under WooCommerce, then Settings, then General.
• Set "Coupon expiry date" to the day after the sale ends. The field's note says the coupon expires at 00:00:00 of that date, so a coupon dated the last day of the sale does not work on that day. To hold a coupon back until the sale opens, schedule it in the Publish settings.
• Read the coupon's other tabs. Under "Usage restriction", "Exclude sale items" stops the coupon applying to products on sale, which may be everything you sell that week, and "Individual use only" stops it combining with another coupon. Under "Usage limits", "Usage limit per coupon" is the total across all customers.
• Test both on staging. Give one product a sale price that includes today, apply the coupon, and read the totals in the cart and at checkout.

Set stock and backorders

• Decide whether the store may sell what it does not have. On each product, under Inventory, "Stock management" tracks a quantity. With it on, "Allow backorders?" offers "Do not allow", "Allow, but notify customer" and "Allow". Under the last, a product on backorder looks no different to a customer from one in stock. A product whose stock is not tracked can be sold without end.
• Count the stock, correct each "Quantity", and read "Hold stock (minutes)" under WooCommerce, then Settings, then Products, then Inventory. Stock is held for an unpaid order for that many minutes, then the pending order is canceled and the stock released. A long hold keeps stock from buyers who would pay.
• Check who is told. On the same screen, the low stock and out of stock notifications should be enabled, and "Notification recipient(s)" should be an address someone reads.

Check tax and shipping at a discounted total

• Read the tax line on the staging order. WooCommerce's documentation says coupons apply to product prices before tax is calculated.
• Check a "Minimum spend" coupon. The documentation says the minimum is measured against the cart subtotal plus tax.
• Check free shipping. A sale price lowers the cart total, so a cart that used to qualify may not. Go to WooCommerce, then Settings, then Shipping, then Shipping zones, and open the free shipping method in each zone. Where "Free shipping requires" is set to a minimum order amount, "Apply minimum order rule before coupon discount" decides which total counts. Unticked, it is the amount after the coupon.
• Test an address in every zone you ship to.

See the order emails arrive

• Send a test. Go to WooCommerce, then Settings, then Emails. "New order" goes to the store, to the "Recipient(s)" set there, and "Processing order" goes to the customer after payment. Use "Send a test email" with an address outside your own domain.
• Read the log for real orders. Under WooCommerce, then Status, then Logs, the transactional-emails log marks each attempt Sent, Failed, Disabled or Skipped. "Sent" means only that WooCommerce handed the message to the site's mail system.
• Ask your mail service what its sending limit is. WooCommerce's documentation warns that a mailbox provider used for the store's mail can run into one. Compare the limit with two emails for each order you expect. How to set up WooCommerce email notifications covers delivery.

Check what the caches leave out

WooCommerce's caching guide names three pages that must stay out of every cache: Cart, My Account and Checkout. It says caching plugins often exclude them already, and that some hosts with server-side caching do not keep the My Account page out.

• Confirm which pages those are. Go to WooCommerce, then Settings, then Advanced. "Page setup" shows the page used for each. The exclusions in every cache must match those addresses.
• Check every cache in front of the store: a plugin, the host's own, a content delivery network. The steps, the cookies to exclude and a test with two browsers are in how to speed up a WooCommerce store.

Save the system status report

Go to WooCommerce, then Status, and select "Get system report". Keep a copy. It records the versions of WordPress, WooCommerce, PHP, the theme and every active plugin as they were when the tests passed.

The week of the sale: set the watch and write the plans down

• Monitor the cart and checkout pages as well as the home page. The home page can be answered from a cache while the checkout, which is built for each visitor, fails.
• Decide how the orders will be watched. An uptime check shows that a page answered, and tells you nothing about payment. The orders do. Decide the longest gap between orders that would be normal during the sale, and who looks at WooCommerce, then Orders, that often.
• Write the rollback plan. In order: undo the last change, switch to a second payment method, restore a backup last. A restore puts the database back as it was, and the orders taken since go with it. The checkout-down runbook explains each step. Set up its second payment method now and leave it switched off.
• Back up more often. Take a full backup before the first day, and back up the database more often on the days of the sale.
• Check again that every gateway is in live mode. WooPayments shows a notice at the top of its screens while test mode is on.
• Read the logs once, so you know what normal looks like. Under WooCommerce, then Status, look at Logs for a fatal-errors file and at Scheduled Actions for failed entries.
• Finish the contact sheet. Phone numbers for whoever is on call, the support routes for the host, the payment provider and the mail service, and where the backups are. Check that each login works. Keep the sheet somewhere other than the store's own server and mailbox.
• Put a figure on an hour of lost sales with the downtime cost calculator. It shows how much preparation the day is worth.

The day itself

• Open a sale product in a private window when the sale starts. WooCommerce's documentation says WP-Cron schedules sale prices, runs when someone visits the site, and can be late when few people are visiting. If the old price shows, load a few pages and look again. If the product page shows the old price and the cart shows the new one, a cache is holding the old page: empty it. Then apply the coupon in the cart.
• Watch the first real orders. Each should reach "Processing", by each payment method, and the emails should arrive.
• Look at the orders as often as you decided. A run of "Failed" or unpaid "Pending payment" orders from one payment method is a fault.
• Look for a fatal-errors log with today's date, and watch the stock of the products you expect to sell out.
• Make no change that is not a repair.

If something breaks

Do not start switching plugins off on the live store. Go to the WooCommerce checkout-down runbook and work from the top. It begins by finding where an order stops, keeps orders coming in while you repair, and ends by accounting for every payment made during the fault. For the fault itself, see WooCommerce checkout not working and WooCommerce payment gateway errors.

The day after

• Check that the sale ended. Open a sale product in a private window, and confirm the coupon is refused.
• Compare payments with orders. Go through the provider's payments for the sale beside WooCommerce's orders. The runbook's section on lost and doubled orders has the method.
• Read the unpaid orders. The WooCommerce failed orders calculator works out what the store did not collect from orders that were started and never paid.
• Clear the queue. Under WooCommerce, then Status, then Scheduled Actions, look for pending or failed actions left from the busy hours.
• Count the stock again, and write to customers whose orders are on backorder.
• Lift the freeze. Apply the updates that waited, on the staging copy first, and switch automatic updates back on where you had them.
• Put the backups back on their usual schedule, and delete staging copies you have finished with.
• Write down what happened: the busiest hour's orders, what the host's dashboard showed against the plan's limits, and anything that went wrong. It is the first page of the next sale's checklist.

If you would rather hand the upkeep over, our WooCommerce maintenance service is the Store care plan: updates are tested on a staging copy first, and checkout and payment are tested after every update.