The SOAP client with no timeout
Slow carts, 503s, 524s, and not one error in any log. The integration client was configured to wait forever, and nothing else in the stack was willing to stop it.
The reports were the vague kind. The cart is slow. Sometimes it times out. Sometimes a 503, sometimes a 524. Nothing in the logs.
That last part was the useful bit, though it took me a while to treat it as evidence rather than as an absence of evidence.
Nothing capped the request
The integration client called the ERP through Guzzle with no request options at all, and nothing in the dependency injection configured the HTTP client either. Guzzle defaults timeout and connect_timeout to 0, which means wait forever.
Nothing further up cared either. The PHP-FPM pool had max_execution_time = 0 and a terminate timeout of four hours. So a single stalled call from the ERP occupied a worker for as long as the ERP felt like being quiet.
Why the logs were empty
This is the part I want to underline, because it inverts a normal instinct.
Guzzle never timed out. Because it never timed out, it never threw. Because it never threw, nothing was ever logged. There was not a single cURL or Guzzle error anywhere, and the ERP looked healthy in every dashboard because it was not returning errors, it was returning nothing at all, slowly.
An empty error log is not proof that the dependency was fine. Sometimes it is the symptom.
The signature that identifies it
Two things made this diagnosable without access to the ERP.
Only the queries that touched the pricing backend hung. Everything else in the same page load stayed under about 400 milliseconds. A sick server slows everything down; a stalled dependency slows exactly the calls that use it. That split is the diagnosis.
The 503 at around sixty seconds and the 524 at a hundred were not two faults. They were two different proxies giving up on the same hung worker at their own configured limits.
Once you see it that way the fix is unglamorous. Set an explicit timeout on the client, decide what the page should do when the dependency is slow, and make sure that decision produces a log line. A dependency that can hang forever will eventually hang forever, usually during a sale.