The path to watch
A store earns money along one path: a visitor opens the catalogue, adds a product, opens the cart, goes through checkout and receives an e-mail. An outside monitor can reach the public parts of that path. It cannot complete a payment, and it should not create orders, so the last steps need other evidence: the gateway’s own dashboard and a test order after each release.
What it can reach is more than the home page. WooCommerce publishes a Store API with “public Rest API endpoints” for cart, checkout and products under /wp-json/wc/store/v1/. The documentation says the Store API “is unauthenticated and does not provide access to sensitive store data”. A request to /wp-json/wc/store/v1/products therefore proves that WordPress, WooCommerce and the database answered, without a login and without touching private data.
What goes wrong on a WooCommerce store
Cached pages that must stay dynamic. WooCommerce’s guidance on caching plugins says the Cart, My Account and Checkout pages should be excluded from the cache, because they show information that belongs to the current customer. A host setting, a caching plugin or an update can put a rule back that caches them. The page still answers 200, so only a check that looks at the page or its timing notices.
Scheduled actions that stop. WooCommerce uses Action Scheduler, a job queue that “will attempt to run every minute” by attaching itself to WP-Cron and also starts a queue from an asynchronous request after an admin request. Because WP-Cron is “only triggered on page load”, a quiet store or a store with cron turned off can leave queued work waiting. Action Scheduler marks an action that runs longer than five minutes as failed. A stalled queue shows up as e-mails that arrive late, not as an error on a page.
A slow checkout. A store can answer every request and still lose orders to a checkout that takes ten seconds. The response time of a page is data, not an outage, so look at it as a trend. Beamfar records DNS, connect, TLS and first-byte times for a page check, shows the 50th and 95th percentile per region and can send a slowdown notice when the time stays above a limit you set.
E-mail that does not arrive. Order e-mails leave through DNS records the store depends on. A change to the SPF, DKIM or DMARC record can send them to spam without any change on the website. See Email stops after a DNS change.
Which checks matter most
| Check | What it catches here | How to set it up in Beamfar |
|---|---|---|
| Home page with required text | The error screen, an empty theme, a maintenance page | The page check; require a phrase from the footer |
| Store API products | The catalogue not loading, PHP or database trouble behind a cached home page | An API check: GET /wp-json/wc/store/v1/products?per_page=1, status 200 |
| Cart and checkout addresses | A broken page, a redirect to the wrong place, a slow response | An API check on each address: status 200 and a response-time limit |
| Heartbeat for scheduled actions | A queue that stopped | A scheduled-task check and a system cron line, as in the WordPress page |
| Search visibility, certificate, domain, DNS | A noindex after a staging copy, an expired certificate, a changed record | Automatic on every site |
Set it up
- Add the shop’s host name in the portfolio. Page, certificate and DNS checks start.
- Set the page check’s required text to a phrase from the footer.
- Add one API check for the Store API products request and one each for the cart and checkout addresses. Expect status 200 and set a response-time limit that matches what the shop owner accepts.
- Add the scheduled-task check for the queue. Use a period of five minutes and a grace time of a few minutes, and call the ping URL from the system cron after due events have run.
- Put the alert where the person on duty reads it, and agree what a regional issue triggers.
What an outside check cannot see here
It cannot see a payment that fails inside the gateway, stock that is wrong, an order that was never created or a coupon that stopped working. It does not log in, so it cannot read the dashboard’s list of scheduled actions. It also cannot tell a shopper’s basket from an empty one on a cached page. Set the checks above, then test the purchase path by hand after each release and keep the maintenance routine for the rest. For why a page that answers is not proof that it works, read What a 200 response hides.
How Beamfar helps
Beamfar is not a WooCommerce extension and does not know which plugin is active. It calls a store down only when two regions agree and keeps the status code, redirects, certificate and DNS answer in the incident, and it records response times for the checks you add. The page check, API checks with assertions, scheduled-task checks and the site crawl are built. It has been tried on test pages only and has no customers yet.
Questions
Can I monitor a WooCommerce checkout without placing an order?
Partly. An outside check can request the checkout address and the public Store API and test the status and the response time. It cannot complete a payment, so test a purchase by hand after a release.
Why does a WooCommerce store answer 200 and still lose orders?
A cached cart or checkout, a payment gateway error or a queue that stopped does not change the status of the page. Watch the specific addresses, the response time and a heartbeat for scheduled actions.
How often should a store be checked?
Pick the interval from what a minute of downtime costs the shop. Beamfar checks every minute on the paid plans, every 30 seconds on Team and up when you set a check to it; see How often should you check a website.
Do the checks work behind a CDN or a cache?
They see what any visitor sees. A CDN or cache can answer while the application is broken, which is why the Store API request is a useful second opinion.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- WooCommerce developer documentation, Store API (developer.woocommerce.com)
- WooCommerce documentation, Configuring caching plugins (read through a search summary of the page) (woocommerce.com)
- Action Scheduler, background processing job queue for WordPress (actionscheduler.org)
- WordPress Plugin Handbook, Cron (developer.wordpress.org)