A WooCommerce problem can look very different: the checkout is not working, a payment method is missing, an order remains in the wrong status, a shipping method does not appear, or suddenly something behaves differently after an update.
In such situations, it is usually not a good idea to change settings randomly or deactivate several plugins at the same time. While this can sometimes accidentally resolve a problem, you still won't know the actual cause afterwards.
Instead, clean troubleshooting follows a simple principle:
Describe the problem precisely → reproduce → narrow down the affected area → check logs and system status → test the cause in a controlled manner → fix it only after that.
Important: When troubleshooting, whenever possible, change only one thing at a time. Test again afterward. That is the only way you can tell which change actually made a difference.
First, describe the actual problem #
„WooCommerce is not working“ is far too vague for troubleshooting.
Try to capture instead what is actually happening.
For example:
„When a customer orders with a delivery address in Germany, no shipping method appears in the checkout. Shipping works with a Swiss address.“
This description already contains important notes: the shopping cart works, the checkout is loading, and the problem seems to be related to shipping and the customer address.
Also note:
- What did you want to do?
- What did you expect?
- What actually happened?
- Can you repeat the problem?
- Does it occur with all customers or only under certain conditions?
- Since when does the problem exist?
- Was anything changed or updated immediately before that?
The more precisely you can narrow down the problem, the fewer areas you will have to investigate later.
Try to reproduce the problem in a controlled manner #
A reproducible bug is much easier to investigate than a problem that „sometimes happens somehow.“.
Therefore, open your shop in a private browser window if possible and repeat the exact sequence of steps where the error occurs.
In the case of a checkout problem, for example, this could mean:
- Add a specific product to the shopping cart.
- Open checkout.
- Use the same shipping address.
- Select the same shipping method or payment method.
- Place the order again or proceed up to the problematic step.
If the error occurs again, you have a reproducible test case. You can repeat this after every change.
In a live shop: Do not run risky experiments with real customer data or production payments. For extensive testing, a staging or test environment is much better suited.
We explain how to perform a complete test procedure in the article Testing a WooCommerce shop before launch: Test order and checklist.
Narrow down the affected area #
WooCommerce consists of many areas that are connected to each other. Nevertheless, in the event of a specific problem, the entire shop does not have to be investigated.
| Problem | First section for the exam |
|---|---|
| Product cannot be purchased | Product status, price, inventory level, and product type |
| Variant cannot be selected | Attributes and variants of the product |
| Shipping method missing | shipping zone, customer address and shipping method |
| Payment method missing | Payment settings and payment provider requirements |
| Payment failed | Order notes and logs of the payment extension |
| Order has unexpected status | Payment method, order notes and status history |
| Order email is missing | E-mail settings and transactional emails log |
| Background task is not running | Scheduled actions and logs |
| White screen or fatal error | Fatal Error or PHP error log |
This limitation prevents you from changing the shipping configuration, for example, even though the payment is actually failing.
Orders and order notes provide important clues #
If the problem is related to a specific order, you should first [look it up/access it] under WooCommerce → Orders Open.
Check the order status, the payment method used, shipping method, customer data, and the order notes.
WooCommerce and extensions can, for example, store information on payments, status changes, or other processing steps in the order notes.
In the event of a payment issue, it may be apparent there, for example, that a payment attempt has failed. In this case, it would be wrong to simply manually set the order to „Processing“ and thereby mask the actual problem.
We explain how to read and manage orders correctly at Managing WooCommerce orders: status, payment, and shipping.
Check the WooCommerce system status #
One of the most important sources of information for technical diagnosis can be found at:
WooCommerce → Status
The system status displays a lot of information about your WordPress and WooCommerce installation. This includes, among other things:
- WordPress and WooCommerce version
- Server and PHP environment
- PHP memory limit
- Database information
- active and inactive plugins
- active theme and child theme
- WooCommerce pages
- WooCommerce template information
- Action Scheduler
The report helps you above all to identify anomalies and potential compatibility issues.
Important: Not every value in the system status is automatically an error. The report provides technical information and notes. The crucial factor is always whether an anomaly actually matches the observed problem.
Copy system status for support #
WooCommerce allows you to provide the system status as a report for support.
Under WooCommerce → Status Can you access the system report and copy or download it for a support request?.
This is much more helpful than simply writing:
„My WooCommerce is not working.“
For example, a support representative can use the report to see which WooCommerce, WordPress, and PHP versions are being used, which extensions are active, and which theme is deployed.
How to use WooCommerce logs correctly #
You can find the second central information source at:
WooCommerce → Status → Logs
WooCommerce has its own logging system. WooCommerce itself and many extensions can log errors, warnings, and technical events there.
Therefore, which logs are available depends on your shop and the installed extensions.
Look for a log whose timestamp and source match your problem as closely as possible.
For example, if a payment failed at 2:32 PM, a matching log entry from that time is much more interesting than an error from three weeks ago.
A log entry is an indication, not automatically the cause. What is crucial is whether the time, affected component, and error message match your reproducible problem.
Take fatal errors seriously first #
WooCommerce automatically logs fatal PHP errors in its logs. You can find such entries under WooCommerce → Status → Logs in the corresponding fatal error entries.
A fatal error means that PHP had to abort the processing in question due to a severe error.
Such an entry typically contains technical details such as:
- Time of the error
- Error message
- affected PHP file
- Line number
- further technical information on the procedure
Not every line is understandable to a layperson. However, the file path often makes it possible to tell whether the error originates from WooCommerce core, a specific plugin, or the theme, for example.
Do not edit PHP files directly: If an error points to a plugin file, you should not simply modify the program code of that file. During an update, such changes would be overwritten, and an incorrect change can cause further errors.
Logs from payment and other extensions #
Many WooCommerce extensions have additional diagnostic logs. Especially with payment providers, these are often very helpful.
Such logs must first be activated in their settings depending on the extension.
Therefore, if, for example, a credit card payment fails, you should not only look at the WooCommerce order status. Also check the order notes and – if available – the log of the payment extension actually used.
The exact designation and content of such logs differ from provider to provider.
You can find more about the interaction between order and payment under Setting up and managing payment methods in WooCommerce.
Check scheduled actions #
WooCommerce and numerous extensions do not execute certain tasks immediately during a page load, but process them in the background.
For this purpose, among other things, the Action Scheduler used.
You can find the overview at:
WooCommerce → Status → Scheduled Actions
There you can see if tasks, for example:
- pending,
- completed,
- failed
- or aborted
are.
Individual failed actions do not automatically mean that your entire shop has a problem. However, if many tasks are piling up or the same action keeps failing, the cause should be investigated.
Fatal errors can, for example, cause a background task not to complete successfully.
Check if the problem started after a change #
The timing of an error is often a very good clue.
Ask yourself:
What was changed immediately before that?
This could have been an update to WooCommerce, WordPress, a plugin, or a theme, for example. Alternatively, a new extension might have been installed, a setting changed, or custom program code added.
If a shop has been working for months and a reproducible problem occurs immediately after a specific change, that change is one of the first things that should be examined more closely.
That doesn't prove yet that it is the cause. However, it provides a concrete starting point.
Updates are part of the diagnosis – but controlled #
Outdated versions of WordPress, WooCommerce, plugins, or themes can cause errors and compatibility issues. Current versions also include bug fixes and security updates.
However, that does not mean you should randomly update everything in the middle of ongoing troubleshooting.
For a production shop, a controlled approach is advisable:
- Document current state and problem.
- Ensure that a current backup is available.
- Test in a staging environment if possible.
- Perform updates in a controlled manner.
- Retest the previously documented error.
That is the only way to tell if the update actually fixed the problem.
Systematically test for plugin conflicts #
WooCommerce often works with many extensions simultaneously. An error can therefore be caused by a conflict between two plugins.
For a meaningful conflict test, the environment is gradually reduced.
In a secure test environment, for example, you can deactivate all unnecessary plugins and leave only WooCommerce and the extension strictly required for the specific test active.
Test again afterwards.
Once the error has disappeared, you reactivate the remaining plugins in a controlled manner and test again after each change. As soon as the error returns, you have a strong indication of the component involved.
Do not perform blindly in the live shop: Disabling payment, shipping, security, cache, or other important plugins can alter ongoing store operations. Therefore, extensive conflict testing should preferably be performed in a staging environment.
The theme can also cause a conflict #
Not only plugins can affect WooCommerce. The active WordPress theme also contains program code and can modify product pages, the shopping cart, or the checkout, for example.
WooCommerce therefore also recommends the temporary use of a known compatible standard test theme such as during a complete conflict test Storefront.
If the problem disappears with the test theme while plugins and other conditions remain unchanged, this is a clear indication that the previous theme or its customizations are involved in the problem.
This test, too, should ideally not be conducted visibly for normal visitors on a live store.
Health checks can facilitate conflict testing #
WordPress provides with the plugin Health Check & Troubleshooting a special troubleshooting mode available.
This mode allows a logged-in administrator to test modifications to plugins and themes for their own session without normal visitors seeing the same test configuration.
This can be helpful during a conflict test.
Still, remain cautious: A troubleshooting mode does not replace a complete staging environment. Especially for payments, external interfaces, background processes, and real orders, a separate test environment is the cleaner solution.
Cache can distort troubleshooting #
Caching speeds up websites, but during troubleshooting, it can prevent you from seeing the current version of a page immediately.
Therefore, depending on the cache system used, a targeted clearing of the relevant cache may be necessary after making changes.
The browser itself can also cache files. A private browser window can therefore be helpful during frontend testing.
Do not deactivate or delete all performance settings on suspicion. Check first whether caching can even be related to the specific problem.
Distinguish between frontend errors and server errors #
Not every WooCommerce problem originates on the server.
For example, if a button does not respond, a checkout area does not update, or elements suddenly disappear, JavaScript or the rendering in the browser may also be involved.
A PHP fatal error, on the other hand, is a server-side error.
Therefore, for an initial classification, the following question helps:
Does the page load completely and only a specific operation is not working – or does the processing fail completely with an error message?
For more in-depth browser diagnostics, the browser's developer tools can be helpful. However, these are intended more for experienced users or technical support.
Not every error message comes from WooCommerce #
A WooCommerce store consists of more than just WooCommerce.
WordPress Core, theme, plugins, payment providers, external interfaces, PHP, database, web server, and other services work together.
An error message in the checkout can therefore originate from a payment extension, for example, even though it is displayed on a WooCommerce page.
Therefore, examine an error message as closely as possible:
Which component is named? Does a plugin name appear? Is there an error code? Can you find a matching log entry at the same time?
This information is usually more valuable than the page on which the error became visible.
When you shouldn't keep trying yourself #
A systematic diagnosis does not mean that you have to repair every technical fault yourself.
At the latest in the event of serious PHP errors, database problems, recurring server errors, or issues with live payments, you should not make changes to the program code or database on a whim.
You should not publicly publish error messages containing access data, API keys, or other sensitive information either.
Your task could initially be to cleanly isolate the problem and compile the relevant information for the responsible support team.
What a good support request should contain #
The better a technical inquiry is documented, the faster a problem can usually be investigated.
A helpful support request contains:
- a detailed description of the problem,
- the expected behavior,
- the actually observed behavior,
- the exact steps to reproduce the error,
- Time or period of the error,
- relevant error messages,
- matching screenshots,
- relevant log entries,
- the WooCommerce system status,
- Information about tests already carried out.
Instead:
„Checkout is not working.“
for example, the following information is much more helpful:
„Since the update of plugin X, an error message appears during checkout with product Y after selecting payment method Z. The error can be reproduced in a private browser window. The following message appears in the WooCommerce log at the same time ...“
This lets support know what has already been tested and where the investigation can begin.
A simple diagnostic sequence for everyday life #
You don't need to memorize every technical possibility for your daily work. For most WooCommerce problems, the following sequence helps:
| Step | What you are checking |
|---|---|
| Problem | What exactly is not working? |
| Reproduction | Can the error be reliably reproduced? |
| Area | Product, checkout, shipping, payment, order, email, or background process? |
| Order | If available: check status, notes, payment, and shipping. |
| System status | Are there any noticeable versions, server values, plugins, theme or template notes? |
| Logs | Is there a matching entry at the time of the error? |
| Changes | What was changed immediately before the first occurrence? |
| Conflict test | Can an involved extension or the theme be identified in a controlled manner? |
| Solution | Only now, specifically fix the identified cause. |
| Control | Rerun the original test case completely. |
This method turns a nonspecific „WooCommerce isn't working“ step by step into a concrete and investigatable problem.
Summary #
Good WooCommerce troubleshooting doesn't start with random changes, but with as accurate a description as possible and a reproducible test case.
Then narrow down the affected area. In the event of ordering problems, the order status and order notes often provide initial clues. Under WooCommerce → Status you find important information about the technical environment. Under WooCommerce → Status → Logs can you search for errors that temporally and contextually match the problem.
For background processes, you should also check the scheduled actions. If a plugin or theme conflict is suspected, it should be checked and, if possible, tested in a staging environment.
Always change only one thing at a time and then repeat the same test. This way you can determine if a change actually affected the cause.
And if the problem requires technical expertise, a clean diagnosis is still valuable: with system status, logs, error messages, and reproducible steps, the responsible support team can search for the cause much more effectively.
