If you're here mid-incident, work through the checklist in order — it's sequenced from most-likely and fastest-to-check down. If you're here after fixing one of these at 11pm, skip to the last section, because the real problem is that nothing told you.
First: Establish What "Broken" Means
Before touching anything, reproduce the failure yourself and note exactly where it stops. The fix path is different for each of these:
The checkout page doesn't render — blank page, fatal error, or an endless skeleton loader. Usually a PHP fatal or a JavaScript crash.
The page renders but "Place Order" fails — spinner, generic "an error occurred," or a validation complaint on fields that look fine. Usually a payment gateway, session, or AJAX/API problem.
The order goes through but something downstream is wrong — no confirmation email, order stuck in pending, stock not reduced. Usually a webhook, cron, or gateway callback issue.
Also check: does it fail for guests and logged-in customers? On mobile and desktop? With every payment method or one? Two minutes of scoping here saves an hour of guessing.
The Checklist, In Order
1. Check what changed last. The update log is your prime suspect list. WooCommerce core, the payment gateway plugin, the theme, and anything that touches checkout fields or shipping are the usual offenders. If a plugin auto-updated overnight, start there — plugin updates are the single most common cause of checkout breakage.
2. Look at the browser console, not just the page. Open dev tools on the checkout page. A red JavaScript error at load or at the moment you click "Place Order" points at a script conflict — often between the payment gateway's script and an optimization or consent plugin. The Network tab shows the failing request: a 403 there is commonly a security/firewall plugin or an expired nonce; a 500 is PHP.
3. Test with the gateway in sandbox/test mode. If the failure is at payment, switch the gateway to test mode (or use its test card numbers). If test mode works and live doesn't, the problem is credentials, webhooks, or the gateway's side — check the gateway plugin's own log and your account dashboard for declined webhook deliveries.
4. Rule out caching and optimization. Checkout and cart pages must never be cached, and their scripts must not be minified into a combined bundle that loads out of order. If you run a caching plugin, a CDN, or an optimizer: exclude /cart/, /checkout/, and the WooCommerce session cookie, purge everything, and retest. This one causes "works for me, broken for customers" more than anything else.
5. Do the conflict binary-search. On a staging copy if at all possible: switch to a default theme (Storefront), retest. If fixed, it's the theme. If not, disable all non-WooCommerce plugins and re-enable in halves until the failure returns. Tedious, reliable, and still the fastest route when the console gives you nothing.
6. Check the Store API and AJAX endpoints directly. Blocks-based checkouts talk to the WooCommerce Store API; classic checkouts post to admin-ajax or the checkout endpoint. If those requests return errors in the Network tab, verify a security plugin, WAF rule, or permalink change isn't blocking them — a failing Store API breaks checkout while the page itself looks perfect.
7. Read the logs where WooCommerce actually writes them. WooCommerce → Status → Logs (fatal-errors log first), plus the gateway's log if it keeps one. A fatal with a plugin path in the stack trace usually ends the investigation.
8. Roll back deliberately. Once you've identified the updated component, roll it back to the last working version and pin it until a fix ships. Rolling back blindly without steps 1–7 works too — but you won't know which update to hold back, so it breaks again on the next update run.
After the Fix: Make the Next Break Impossible to Miss
Here's the uncomfortable part of every checkout incident: the question is never just "what broke?" — it's "how long was it broken before anyone noticed?" For most stores the honest answer is somewhere between hours and days, and the cost of that window is larger than the cost of the bug.
The fix for the window is structural, not heroic:
Run the checkout as a scheduled journey. A real browser walks shop → add to cart → checkout → place order on a schedule and alerts you at the exact failing step, with a screenshot. That turns "checkout is broken" from a customer complaint into a named, evidenced alert minutes after the break. This is what WooCommerce monitoring means in practice — not pinging the checkout URL.
Re-check immediately after updates. Breakage clusters around update day, so verification should too: run the journey and re-capture visual baselines right after your maintenance window instead of waiting for the next scheduled slot.
Watch the API layer separately. Store API monitors catch the wrong-status, wrong-shape responses that precede a visibly broken checkout — often before the storefront shows any symptom at all.
A checkout that fails at 9:05 and pages you at 9:10 is an anecdote. One that fails Friday night and surfaces in Monday's support queue is a revenue report. The checklist above fixes today's incident; the monitoring decides which of those two stories the next one becomes.