Checkout can time out while PHP waits for MySQL to read, lock or write order data. The expensive query may belong to WooCommerce, an extension or custom code triggered during order creation. Increasing PHP timeouts can turn a short failure into a longer customer wait without improving database work.
Reconcile payments before repeating. A timed-out browser does not prove the transaction or database write failed.
Capture the blocked request
Record timestamp, request duration, checkout endpoint, order ID if any and gateway reference. Match it with PHP, web server and MySQL logs.
Useful database evidence:
query fingerprint, not customer values
execution time and rows examined
lock wait
database host/thread
calling plugin or stack where availableRedact addresses, emails, session data and SQL literals.
Enable the slow query log carefully
Use the hosting provider’s supported MySQL slow-log or performance tooling for a bounded period. Choose a threshold low enough to catch checkout delay without collecting an unmanageable volume.
Do not enable general query logging on a busy production store casually; it can expose sensitive values and add disk load.
Protect logs, limit retention and disable temporary diagnostics after collecting evidence.
Distinguish slow execution from lock waits
A well-indexed query can still wait behind a long transaction. Inspect current processes, InnoDB lock waits and deadlock reports during a controlled reproduction.
Product imports, backups or analytics jobs may hold locks on tables checkout needs. Schedule them away from peak trading and commit work in bounded batches.
Do not kill database threads without confirming their owner and transaction impact.
Analyse the query plan
Run EXPLAIN on a sanitised equivalent query in staging. Look at access type, selected indexes, estimated rows and temporary sorting.
EXPLAIN
SELECT order_id
FROM wp_wc_orders
WHERE status = 'wc-processing'
ORDER BY date_created_gmt DESC
LIMIT 20;The example prefix/schema may differ. Do not add an index based on one generic query; inspect the actual store and WooCommerce schema.
Check HPOS compatibility
High-Performance Order Storage reduces dependence on post tables, but extensions using legacy direct queries may still scan wp_postmeta or force compatibility synchronisation.
Review WooCommerce system status and extension declarations. Use wc_get_orders() and CRUD APIs in custom code instead of assembling cross-storage SQL.
Repair failed HPOS sync actions before changing storage modes. Take a backup and test migration work on staging.
Find unbounded application queries
Search the PHP call stack for WP_Query, get_posts() and wc_get_orders() without practical limits. A checkout hook should not load an entire customer history or product catalogue.
Query only required columns/IDs, add stable filters and cache non-personal reference data appropriately. Never cache a customer’s live cart or order response publicly.
Remote API calls can also hold a database transaction open; move non-critical work after durable order creation.
On replicated database setups, verify checkout writes and immediate reads use a consistency model appropriate for orders. Reading a lagging replica can make freshly created data appear absent and trigger unnecessary repeat work.
Apply a bounded repair
Correct the query, index, batch size, lock owner or custom hook demonstrated by evidence. Back up before schema changes and use the hosting’s online-maintenance options where available.
Avoid generic database-cleaner plugins that delete WooCommerce tables or metadata without understanding dependencies.
Verify order creation and database health
Run controlled checkouts with representative carts while monitoring query duration, lock waits and PHP response time. Confirm one order, one payment, stock and email.
Recurring care should track slow-query fingerprints, database growth and the oldest scheduled action. A fast product page does not prove the transactional write path is healthy.