Identify the responding component and correlate its logs with the affected request. Treat retries of payments, forms and imports separately from ordinary page views, and confirm the original workflow after repair.
A 502, 503 or 504 error tells you where a request failed in broad terms; it does not prove that your website needs a new host or that a plugin is broken. Start by recording the exact response, the affected action and the time, then determine which server or gateway generated it.
If the error followed a payment, booking or form submission, check whether that action completed before repeating it. A missing response is not proof that the server did no work. This guide provides an investigation path for website owners, based on official documentation checked on 13 October 2026.
What the three codes mean
| Code | Meaning | First question |
|---|---|---|
| 502 Bad Gateway | A gateway or proxy received an invalid response from an upstream server | Which upstream connection or response failed? |
| 503 Service Unavailable | A server is temporarily unable to handle the request | Is there maintenance, overload or another temporary availability problem? |
| 504 Gateway Timeout | A gateway or proxy did not receive an upstream response in time | What was it waiting for, and did that work later finish? |
The definitions come from MDN’s references for 502, 503 and 504. The same visitor-facing code can arise from different technical causes. A timeout by itself does not identify a database query, external service or PHP worker as the culprit.
A DNS lookup failure or certificate warning is a different starting point. With a 5xx response, some HTTP component answered the request with an error. That component can be a delivery service in front of the application, rather than WordPress itself.
Capture the failed request before changing anything
Record the public URL, code, time and time zone, any request/reference ID shown, and the action immediately preceding the failure. Note whether it was an ordinary page view or an operation that changes data. If possible, capture a screenshot and the response status in the browser’s Network panel.
Remove session tokens, private query parameters and customer details before sharing evidence. A browser network export can include cookies and request contents; do not attach an unreviewed export to a public forum.
- Does the homepage fail, or only one page or action?
- Does a logged-out page fail while administration works, or the reverse?
- Is the problem continuous, intermittent or tied to a long-running export?
- Did it begin after a deployment, import, backup, plugin update or traffic increase?
- Does the hosting or delivery provider report an incident affecting your service?
These observations narrow the investigation without changing production state. Another network can provide a useful comparison, but one successful request does not establish that the outage is over.
Do not repeatedly submit an uncertain transaction
A gateway can stop waiting while the application continues processing. For a purchase, check the order history or ask the merchant to confirm the result. For your own site’s import, inspect the job status and created records before starting it again. Avoid repeated clicks on a slow “Submit” button.
The HTTP Semantics specification limits automatic retries of non-idempotent operations unless the client knows that retrying is safe or that the original operation was not applied. Site owners should use their application’s documented retry and duplicate-prevention mechanisms, rather than assuming all failed HTTP requests can be replayed.
For a normal public article, a modest later retry is usually a different risk from re-sending a payment. Use that distinction when writing your error message: offer readers navigation or a later retry, and give transaction users a way to check status.
Identify the layer that generated the response
A typical request may cross a CDN or reverse proxy, a web server, application workers and a database or external API. Give the host the timestamp and request ID so they can correlate the layers. Page branding can be a clue, but it is not a complete diagnosis.
Cloudflare’s 502/504 troubleshooting documentation, for example, distinguishes errors associated with the origin from errors generated in its own service and requests precise incident details. Follow the guide for the delivery service actually used by your site, rather than applying Cloudflare-specific advice to every host.
Do not remove a proxy, disable a firewall or publish an origin address as a casual test. Those actions can change the site’s security exposure and may create new certificate or routing problems. A host can perform an authorised origin-path comparison while preserving the intended hostname, TLS and access controls.
Investigate a 502 as an upstream failure
Ask the operator to check the gateway error log and the corresponding application or worker log for the same request window. Useful evidence includes a refused upstream connection, a worker exit or a malformed/truncated response. Each points to a narrower repair than “clear all caches.”
If the failure began immediately after a deployment, compare that change with the last known working state. A controlled rollback may be appropriate when the failure is confirmed to be in the release and rollback is compatible with any database changes. Restoring an old database without reviewing new customer data can be worse than the original incident.
When only one route fails, reproduce that route safely and preserve its error. When every application request fails, check the application service and server health before blaming the text of an individual article. Do not restart every account service on shared hosting.
Investigate a 503 as an availability problem
Look first for an intentional maintenance window or an active update. If maintenance was expected, confirm the process is progressing and that the maintenance response will be removed when the operation finishes. A leftover message is not proof that all application files are healthy.
Outside maintenance, ask the host which limit or health condition caused the response. Correlate worker usage, memory, CPU, database connections and relevant task history with the failed requests. A quota alert from another time or another site is not evidence for this incident.
A temporary response can include Retry-After with a delay or date. Use a realistic estimate when one exists; the header does not repair the service or guarantee that every client follows it. Avoid a rapidly refreshing error page that adds traffic during overload.
Investigate a 504 as an unfinished wait
Measure where time is spent. A slow database query, waiting external request or large synchronous operation are possibilities to investigate, not conclusions drawn from the code. Ask whether the application finished after the gateway’s deadline and whether the same request can safely be repeated.
Increasing a timeout can sometimes fit a legitimate supported workload, but it can also leave scarce workers occupied for longer. First determine whether the work should be optimised, broken into smaller batches or moved to the application’s supported background-job workflow. Confirm limits at every relevant layer; changing PHP’s setting alone may leave an earlier gateway deadline unchanged.
For a hypothetical export that normally takes a few seconds but now fails after a large data import, preserve the export parameters and investigate the changed workload. Do not use an unlimited timeout as the default recovery procedure.
Use WordPress logs without exposing visitors to debugging
For a WordPress-specific failure, inspect existing private logs first. If additional logging is necessary, follow the official debugging guidance with appropriate backup or staging preparation. Logging and public error display are separate controls.
Keep debugging scoped and temporary, protect any log files, and remove sensitive content from support extracts. Reproduce with a test account or non-production dataset where possible. A successful administrator request alone does not prove that logged-out pages or checkout are working.
If a staging environment is needed, our private staging guide explains why access control and search visibility need their own checks.
Verify recovery and leave a useful incident record
Recheck the original failing path, a representative public page and the affected application workflow. Use an approved test transaction when relevant, not an unnecessary real purchase. Check that normal status codes have returned and that the original error does not recur in the corresponding logs.
Google’s crawler status documentation explains that server errors can reduce crawling and persistent failures can affect indexing. Return an honest status during an outage instead of a successful code around an error message; no error-page setting guarantees preservation of search visibility.
Keep a concise record of the cause, correction, affected period and acceptance checks. Add a focused monitor for the failure that mattered: a homepage-only check may miss a broken form or export. Recovery means the relevant reader action works again, not merely that the error disappeared once.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: 502 Bad GatewayChecked Gateway/proxy received an invalid upstream response.
Limits: A status code alone does not identify the failing component or vendor. - MDN: 503 Service UnavailableChecked Temporary inability to handle a request, including overload and maintenance examples.
Limits: No assertion that maintenance or resource exhaustion is the proven cause of any actual incident. - MDN: 504 Gateway TimeoutChecked Gateway/proxy did not receive an upstream response in time.
Limits: Timeout does not establish that the upstream action stopped or never completed. - RFC 9110: HTTP SemanticsChecked Section 9.2.2 limits automatic retry of non-idempotent requests unless safety/non-application is known.
Limits: No automatic replay procedure; readers inspect transaction or job outcome first. - Cloudflare: Error 502 or 504Checked Origin and edge failure sources differ; incident URL/time/details aid diagnosis.
Limits: Provider-specific guidance is labelled; no instruction to disable protections or expose origin. - MDN: Retry-After headerChecked Retry-After can specify a delay or date; client support differs.
Limits: Header is not described as a repair or an indexing guarantee. - WordPress: Debugging in WordPressChecked Controlled debugging, backup/staging preparation and separate logging/public display concerns.
Limits: No production debug snippet, public log publication or claim that one successful request verifies a site. - Google: How HTTP status codes affect crawlersChecked Missing pages, soft errors and persistent server failures have distinct crawling/indexing implications.
Limits: No ranking preservation promise, fixed recovery time or instruction to mask failures with HTTP 200.