Configuration checks tell you whether your store is set up sensibly. Monitoring tells you whether real customers are running into trouble right now. A test order tells you whether the basic checkout flow completes. Each answers a different question, and none of them proves that a real customer can pay.
People often use these words as if they meant the same thing. They do not, and mixing them up leads to false comfort (“the score is green, so checkout works”). This guide separates the three, says what each cannot see, and suggests how to combine them.
At a glance
- Configuration checks ask: is the setup sound? They look at settings, pages and background tasks, at a moment in time.
- Monitoring asks: is something going wrong for real visitors? It watches real orders, errors and speed, over time.
- A test order asks: does the checkout flow complete from start to finish? It goes through your checkout, once, on demand or on a schedule.
1. Configuration checks (diagnostics)
What they are. A scan reads your store’s configuration and reports what looks wrong or risky: a checkout page that no longer contains the checkout, a payment gateway left in test mode, shipping or tax setup that does not add up, background tasks that are not running, a very large amount of autoloaded data.
What they are good for. Catching preventable problems before a customer meets them, and giving you a starting point when you inherit a store. They are fast, they change nothing, and you can run them whenever you like.
What they cannot see. They look at settings, not at behaviour. They cannot tell you that a payment button failed for a visitor on one browser, that a gateway is declining payments today, or that an update broke the checkout an hour ago.
The free KODENZO Commerce Health plugin is an example of this kind of tool: 34 read-only checks and a 0 to 100 health score.
2. Monitoring
What it is. Monitoring runs in the background and watches what actually happens. For a checkout, that can mean the share of orders that fail or are left unpaid, JavaScript errors on the checkout page, how fast the checkout loads for real visitors, and what changed (for example a plugin update) just before something started going wrong.
What it is good for. Noticing a problem while it is happening, on a day when nobody is looking at the store. It is the only one of the three that sees real customers’ experience.
What it cannot see. It reacts to events, so it needs traffic: a quiet store gives it little to learn from. It cannot see a failure that happens before an order exists, and a payment form that breaks without any error may go unnoticed. A flagged plugin change is a lead to look at, not proof of the cause.
KODENZO Commerce Health PRO is a paid add-on that does this kind of monitoring. It runs on a 5-minute cycle inside your own site, and its documentation lists what it cannot detect.
3. Test orders
What they are. A test order places an order through your checkout on purpose, so you find out whether the flow works without waiting for a customer to try it.
What they are good for. Checking the basics after a change, such as an update or a theme edit, and on quiet stores where there is not enough real traffic for monitoring to learn from.
What they cannot see. It matters how the test order pays. The Commerce Health test order uses a hidden test payment method that never contacts Stripe, PayPal or any other provider, so a pass says nothing about whether your real gateways work. It also cannot see what other plugins do when an order is created, and the free version does not test shipping, tax or coupons. The test order is real in one sense: it uses an order number and stays in WooCommerce until it is deleted, so it is worth knowing what else on your site reacts to a new order (accounting, shipping, warehouse or messaging tools).
The free plugin has a manual test order for the basic flow. PRO adds a choice of physical or virtual test product, a shipping rate, a temporary coupon, a tax comparison, a check that the order matches the cart, and a schedule.
How they fit together
| Question | Configuration check | Monitoring | Test order |
|---|---|---|---|
| Is the setup sound? | Yes | Partly | No |
| Are real customers failing right now? | No | Yes | No |
| Does the basic checkout flow complete? | No | Indirectly | Yes |
| Does my real payment gateway accept a real card? | No | Only through real orders | No (hidden test method) |
| Does it work on every browser and device? | No | Partly (errors) | No |
The honest last row is that only a real purchase with a real card, in a real browser, answers the question for your actual gateway. Many store owners do this by hand after major changes. Tools reduce how often you need to and help you notice sooner. They do not replace it.
A sensible routine
- Scan after every change that touches the store (updates, a new plugin, a settings change) and act on what it finds.
- Run a test order after updates to confirm the basic flow still completes, on a staging copy first if you can.
- Monitor continuously if checkout is where your revenue is, so a problem on a quiet Sunday does not wait for Monday.
- Place a real order yourself now and then with a real card, and refund it.
Our free WooCommerce checkout checklist turns the manual part into a list.
Frequently asked questions
If my health score is green, does checkout work?
Not necessarily. A score summarises configuration findings. It does not place an order or watch your visitors.
Can a test order replace a real purchase?
No. A test order that uses a test payment method proves the flow up to the payment step. It does not prove your real gateway.
Do I need all three?
A small store can start with scans and an occasional test order. Monitoring earns its place when checkout revenue is large enough that hours of unnoticed failure would hurt.
See also: WooCommerce checkout monitoring and how to know if your WooCommerce checkout is working.