Identify who returned the timeout
A 504 indicates a gateway did not receive a timely response from an upstream server. On a WordPress site the request may pass through a CDN, reverse proxy, web server, PHP worker and database. Capture the affected URL, request time and any edge request ID, avoiding sensitive query strings.
Compare the response with CDN and origin logs for that time. Determine whether the request reached the origin and which upstream was waiting. A single slow report and timeouts across the whole site suggest different scopes.
Investigate the slow component
Check PHP worker saturation, slow-request traces where configured, database slow-query evidence and external API calls. For an admin report or checkout, reproduce the same operation with permission and representative data. Long-running scheduled jobs or locks can delay a web request even when average CPU appears normal.
Inspect network and storage pressure as well as recent deployments. A restart can temporarily free a worker while losing the evidence needed to identify the cause; capture the relevant diagnostics first when service impact permits.
Change the bottleneck, not only the timer
Increasing a proxy timeout can hide a slow dependency and tie up connections longer. Fix or move long work to an appropriate background process, tune resource limits from measured memory and concurrency, and add safe timeouts to external calls.
After a targeted change, repeat the original journey, compare latency and errors, and check that upstream logs no longer show the same wait. Confirm rollback and monitor during a representative peak.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.