How to maintain a WooCommerce store: before every update, every week, every month and before a sale
A store needs the upkeep of any WordPress site, plus what only a store has. Orders arrive all day, the checkout can fail while every page looks right, and WooCommerce has its own database update, templates and background jobs. This page gives a routine for each.
- By
- WP Ministry
- Updated
In short
- A restored backup removes every order taken since it was made. Back up the database often, and restore the whole store only as a last resort.
- After every change, place a test order on a staging copy through each payment method in its test mode. A look at the pages does not show a checkout that has stopped taking money.
- After a WooCommerce update, let its database update finish before you test. Since WooCommerce 9.9 it runs by itself, in the background.
- Every week: read the unpaid orders, the failed scheduled actions and the fatal-errors log.
- Every month: check the theme's copies of WooCommerce templates, the payment and shipping extensions, and how long personal data is kept.
- In the days before a sale, stop updating, and prove that a backup restores.
A WooCommerce store needs everything an ordinary WordPress site needs: updates, backups, a look at the pages, a check on who can log in. The WordPress maintenance checklist has that routine, and how to safely update WordPress has the method for updates. Do both. This page covers only what a store adds.
A store adds four things. Orders arrive all day, so a backup is out of date soon after it is made. The checkout can stop taking money while every page looks right. WooCommerce has parts of its own to look after: a database update, templates and background jobs. And the store holds its customers' names, addresses and orders. Each is explained below. The routine follows, as four checklists.
What a store adds
Orders arrive all the time
WooCommerce keeps products, orders and settings in the database. A backup holds the orders that existed when it was made and none taken since. Restore it and the later orders are gone from the store, though the customers have paid.
- Back up the database more often than the files. How to schedule automatic WordPress backups suggests several times a day for a store and shows how to set that up. WordPress's documentation says to back it up before every upgrade as well.
- Restore last. When an update to an extension breaks the store, going back one version of that plugin leaves the orders in place. A restore does not. The checkout-down runbook leaves a restore until the end for that reason, and says to export the orders placed since the backup before restoring.
- Never push a staging database over the live one. It is the same loss by another route. How to set up a WordPress staging site explains how to send changes back without it.
The checkout is the page to test
On a store, the fault that matters does not show on a page. WooCommerce's own list after an update is to open the storefront and several product pages, add a product to the cart, place a test order, and check shipping, tax, payment and email. Do it twice.
- On a staging copy first, with each payment gateway in its test or sandbox mode. WooCommerce's guide to test orders says test payments belong on staging.
- On the live store afterwards. WooCommerce's update guide asks for a test order there too, with "an appropriate test payment method or low-risk workflow". Check what you can 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. Then watch the next real orders.
On the staging copy, you should see the test order under WooCommerce, then Orders, with the status "Processing", which means payment was received and stock was reduced. An order of only virtual, downloadable products needs no processing and goes on to "Completed". The confirmation email should reach your inbox.
Then delete the test orders. WooCommerce gives a test order no special status, so it sends emails, appears in analytics and can be shipped by mistake.
If an order does not go through, WooCommerce checkout not working covers a checkout that will not load or submit, and WooCommerce payment gateway errors covers a payment that is refused or not recorded.
Extensions keep their own schedule
A payment gateway or a shipping extension is a plugin of its own, often from another company, with its own releases. WooCommerce's guide says to update extensions, themes and payment gateways in the same session as WooCommerce, because compatibility depends on the whole set.
- Extensions from the WooCommerce.com Marketplace. Go to WooCommerce, then Extensions, then My subscriptions. Check that the store is connected to your WooCommerce.com account, and read each item's "Tested up to WooCommerce version". If it is older than the WooCommerce version you are moving to, look for an update to the item or read its release notes first.
- Anything else. The release notes and compatibility advice are with its developer.
The rules can also change outside your store. In September 2019 a regulation called Strong Customer Authentication took effect in the European Economic Area. It requires two independent checks of a customer's identity for online payments. WooCommerce advised stores to update to payment methods that supported it, and warned that a gateway that was not ready would see declines increase. So read the mail your payment provider sends and the changelog of your gateway's plugin.
The database update after a WooCommerce update
Some WooCommerce updates change the database as well as the files. The release notes for WooCommerce 9.9 say that, from that version, all stores run these database updates automatically, in the background. No notice asks you to start one, so the backup has to exist before you update the plugin.
To see that an update has finished, go to WooCommerce, then Status, then Scheduled Actions, and search for woocommerce_run_update_callback. Each step of the update is an action with that name: wait until none is pending. WooCommerce also writes what it scheduled to a log named wc-updater, under WooCommerce, then Status, then Logs.
A developer can switch the automatic update off with the woocommerce_enable_auto_update_db filter. On such a store a "WooCommerce database update required" notice appears in the dashboard once the plugin has updated, with two choices: "Update WooCommerce Database" and "Learn more about updates".
After you select it, a "WooCommerce database update" notice appears. Its "View progress" link opens Scheduled Actions, where the pending update actions are listed. When they have run, a "WooCommerce database update complete" message appears.
Templates copied into the theme go out of date
A classic theme can replace one of WooCommerce's template files by keeping its own copy in a woocommerce folder inside the theme. WooCommerce's documentation notes that its own templates will update and the copies will not. After an update, the theme may be drawing the cart or the checkout from an old file.
Go to WooCommerce, then Status. The Templates section, at the end of the System Status report, lists the files your theme overrides and notes the ones that are outdated, with a line such as "version 3.5.0 is out of date. The core version is 3.7.0".
Update the theme first: WooCommerce's guide says most theme authors fix their templates in good time. If the copy is your own, in a child theme, the guide's method is this. Save a backup of the outdated file. Copy the current file from wp-content/plugins/woocommerce/templates/ into the same place in the theme. Then make your changes again in the new file. Do it on a staging copy and test the page that template draws. To undo it, put the saved file back. All of this applies to classic themes, whose templates are PHP files.
Background jobs can pile up or fail
WooCommerce and its extensions hand work to a queue called Action Scheduler. WooCommerce's documentation lists subscription renewals, some customer emails and webhooks among the tasks it carries. By default the queue is started by WP-Cron, which runs when someone visits the site, so on a quiet store tasks can run late.
The queue is under WooCommerce, then Status, then Scheduled Actions. It shows which tasks completed, which are pending, and the error for any that failed. Action Scheduler's own guidance is that some past-due actions are normal, and that several more than a day old may mean something is wrong with the site. How to speed up a WooCommerce store explains how to read the failed entries. The backup guide linked above shows how to run WP-Cron from the server's clock.
Customer and order data is personal data
A store holds a name, an address and a history of purchases for each customer, and it keeps them until you say otherwise.
- Orders and accounts. Go to WooCommerce, then Settings, and select the Accounts and Privacy tab. Under "Personal data retention", set how long to keep inactive accounts and pending, failed, canceled and completed orders. A field left blank keeps that data indefinitely. With a period set, WooCommerce cleans up daily. It moves pending, failed and canceled orders to the trash, anonymizes completed orders so that sales figures stay accurate, and deletes inactive accounts. WooCommerce says to state these periods in your privacy policy and to make sure they comply with the laws that apply to you.
- Logs. Under WooCommerce, then Status, then Logs, the Settings screen has a "Retention period". The default is 30 days.
- Exports and copies. A database export, a downloaded backup and a staging copy each hold the same customer data as the live store. Keep each only while it is needed, then delete it.
Before any update
- Read what is waiting. Go to Dashboard, then Updates. Before a WooCommerce update, read its changelog, and read "Tested up to WooCommerce version" for each extension.
- Refresh the staging copy and apply the updates there. Put the gateways in sandbox mode and place a test order.
- Back up the database, now. Use your backup tool, or WP-CLI as shown below. Download the file and remove it from the server.
- Keep customers out of the checkout while you work. WooCommerce's guide suggests setting the store to Coming soon mode for the update, so that nobody checks out while files and the database are changing.
- Apply the same updates to the live store. WooCommerce first, then extensions, the theme and the payment gateways.
- Let the database update finish. Wait until no
woocommerce_run_update_callbackaction is pending under Scheduled Actions. If a notice asks you to start the update, select "Update WooCommerce Database" first. - Go through the checkout as far as the payment step, and check that each gateway's settings show a live connection with test mode off.
- Read WooCommerce, then Status. Look at the Templates section, the failed entries under Scheduled Actions, and any
fatal-errorsfile with today's date under Logs. - Open the store again, and watch the first real order through each payment method reach "Processing".
With WP-CLI, the first command exports the database and the second runs the pending WooCommerce database updates. Run each at its own point in the list above.
wp db export ~/before-updates.sql
wp wc updateThe ~/ writes the export to your home folder. A file in the site's own folder can be downloaded by anyone who guesses its name. The second command answers "No updates required" when the automatic update has already finished.
Every week
- Read the unpaid orders. Go to WooCommerce, then Orders. "Failed" means the payment failed or was declined. "Pending payment" means the order was received and nothing was paid. Abandoned orders are expected. A sudden rise, or a run from one payment method, is a fault: open an order, read its notes, and go to the gateway errors page linked above. The WooCommerce failed orders calculator works out what your store did not collect from orders that were started and never paid, from your own order counts and average order value.
- Clear the orders that are "On hold". They await payment confirmation, and their stock is already reduced. Confirm the payments that arrived and move those orders on.
- Read the failed scheduled actions. WooCommerce, then Status, then Scheduled Actions.
- Read the fatal-errors log. WooCommerce, then Status, then Logs. A new file means PHP failed somewhere this week. Each entry gives the error, and the file and line it came from.
- Read the time of the newest database backup. It should be as recent as your schedule says.
Every month
- Restore the newest backup to a staging copy and find the most recent order in it. The gap between that order and now is what a restore would cost you.
- Read the Templates section under WooCommerce, then Status, for anything outdated. Then go to Tools, then Site Health, where WooCommerce adds checks of its own, among them outdated template overrides and database tables.
- Go through the payment and shipping extensions. Check My subscriptions for updates, read the changelog of each third-party gateway, and look for notices on your account in the provider's dashboard.
- Check the stock notices. Go to WooCommerce, then Settings, then Products, then Inventory. The low stock and out of stock notifications should be enabled, and "Notification recipient(s)" should be an address someone reads.
- Apply your rule for personal data. Check that the retention periods still match your privacy policy. Delete old exports, downloaded backups and staging copies you have finished with.
Before a sale season
- Finish updating early, then stop. Do the last full round, with staging and test orders, a week or more ahead. In the days before the sale and during it, change nothing: no updates, no new plugins, no new cache settings. The exception is a security fix. WooCommerce's guide says those matter more than your schedule, and its Advisories page lists them.
- Prove a restore. Restore the newest backup to a staging copy and note how long it takes. Back up the database more often on the days of the sale.
- Place a test order at the sale price on the staging copy, through each payment method in its test mode, with the coupon if there is one.
- Check scheduled sale prices at the hour they start. WooCommerce's documentation says WP-Cron schedules sale prices, and that its tasks can be delayed when few people are visiting.
- Count the stock and set the hold. Under Inventory, "Hold stock (minutes)" is how long stock is kept for an unpaid order before the pending order is canceled and the stock released. Set "Low stock threshold" high enough to give you time to reorder.
- Check the caches. How to speed up a WooCommerce store lists the pages that must stay out of every cache.
- Keep the runbook at hand, and a second payment method set up and switched off, as the checkout-down runbook advises.
What not to rely on
- A look at the home page. A broken checkout looks normal until someone pays.
- A test on staging alone. It shows that the code works, not that the live keys and your account with the provider are in order.
- Automatic updates for WooCommerce or a payment gateway. They take no backup, and nobody places an order afterwards.
If you would rather hand the routine over, our WooCommerce maintenance service is the Store care plan: updates are tested on a staging copy first, checkout and payment are tested after every update, and order data is backed up more often.
Common questions
How often should a WooCommerce store be updated?
WooCommerce's guide says a monthly cadence works well for most stores. It also says to update sooner when a release includes a security fix or repairs something your store depends on. A weekly round keeps each set of changes smaller. Either rhythm works if every round goes through staging and ends with a test order.
What is High-Performance Order Storage, and does it change my backups?
It keeps orders in database tables of their own, such as wp_wc_orders on a site with the default table prefix, where WooCommerce used to keep them in the tables WordPress uses for posts. It is the default for stores first installed with WooCommerce 8.2 or later. Go to WooCommerce, then Settings, then Advanced, then Features to see which storage your store uses. Whichever it is, the orders are in the database, so check that your backup copies every table. The speed guide linked above covers switching an older store.
The checkout broke after an update. What do I do first?
Go through the checkout as far as the payment step and note where it stops. Do not restore a backup yet. The checkout-down runbook takes it from there, and the failed update runbook covers going back one version.
- ResourceTaking over a client's WordPress site: a checklist to run before you change anything
- Cost guideWooCommerce maintenance cost: why a store costs more, and what the extra should buy
- ResourceWordPress launch checklist: what to check before a site goes live
- Cost guideWordPress maintenance cost: what you pay for, and why prices differ
- ResourceMonthly WordPress maintenance report template
- ResourceA WordPress update went wrong: a runbook

