The checkout works when you test it.
It failed for someone at 03:14.

This is the worst kind of bug: it happens to customers who never tell you, on a request you cannot reproduce, and by the time you look the evidence is gone. Server logs give you a 500 and a timestamp. They do not give you the query, the payment API call, or the plugin that was in the middle of it.

A real result from a working shop with the site name removed. Nothing to install, no account, no address to hand over.

PHPRay records every request, so the one that failed two hours ago is still there. This is what it found in one real shop's week — 39,995 requests:

  • urgent 1,089 responses returned 5xx. Among the evidence: HTTP 500 — /shop/ and HTTP 503 — /checkout/. Nobody had reported either. Each one is a customer who saw an error page instead of paying.
  • worth a look The PHP error is attached to the request. Not in a separate log you have to line up by timestamp — on the same record as the URL, the status, the duration and the queries that ran before it failed.
  • good to know Outbound calls are recorded too. Payment gateways and shipping APIs are the usual cause of a checkout that fails “randomly”: they answer in 80 ms all day and in 30 s at 03:14.

The numbers come from a report the product generates itself, with the shop's name removed.

Sampling tools keep statistics between samples. A checkout that fails three times a day is exactly the request a sample does not contain.

Every request, not a sample

One record per request, kept. The failure that happened once is still there when you look, with everything that ran inside it.

No customer data

SQL is stored as fingerprints with the values stripped: WHERE email = ?. Request bodies, cookies and sessions are never touched — which matters more on a checkout than anywhere else.

Works on shared hosting

No daemon and no agent running as root. If you have your own php.ini — and on most hosting you do — you can run it yourself.

Questions people actually ask

Why does WooCommerce checkout fail for some customers and not for me?

Because the failure usually depends on state you do not have when you test: a specific cart, a payment gateway that timed out, a plugin conflict that only fires for logged-in users. It is a real request that failed once and left nothing behind except a line in the server log.

How do I find the cause of a 500 error I cannot reproduce?

Open the request itself. PHPRay keeps one record per request with the PHP error attached to the same record as the URL, the status, the duration and the queries that ran before it failed — so you do not have to line up separate logs by timestamp.

Are payment gateway and shipping API timeouts recorded?

Yes. Outbound HTTP calls are recorded with their duration, which is how a checkout that fails “randomly” usually explains itself: the gateway answers in 80 ms all day and in 30 seconds once an hour.

How many failing requests does a normal shop have?

More than its owner thinks. In one real WooCommerce shop's week — 39,995 requests — PHPRay found 1,089 responses that returned 5xx, including HTTP 503 on /checkout/. None of them had been reported by a customer.

Do I need root or a daemon to install this?

No. The extension loads from your own php.ini, and the WordPress plugin needs neither an extension nor a daemon. It runs on shared hosting, which is where a large share of WooCommerce lives.

Catch the next one

Free plan: one site, 10,000 traces a day, 7 days of history, no card. The local core is open source and free without limits.

Create a free account Shop is slow, not failing?

On WordPress without root? The plugin does the same thing without the PHP extension, without a daemon and without server access. Plain PHP 7.4+, GPLv2: download the plugin.