What matters first: WordPress or a plugin waited too long for an external service. The important facts are the destination host, operation, timeout value and whether DNS, connection or response time was consumed.
What this symptom actually tells you
This error often appears in Site Health, updates, payment gateways, licences, webhooks or remote APIs. Raising the timeout may hide a slow dependency while keeping PHP workers occupied for longer.
Capture evidence before changing anything
- Capture the complete error, including URL and timeout duration.
- Test DNS resolution, TCP connection and HTTPS response separately from the server.
- Identify the plugin, theme or core operation that made the request.
- Compare one failed request with a successful request from another network or host.
Most common causes
- Remote service latency: The API or vendor endpoint is slow or unavailable.
- DNS delay: The server cannot resolve the destination promptly or consistently.
- Outbound firewall: Hosting or security rules block the destination or port.
- Worker saturation: The local server is too busy to begin or complete the outbound call in time.
Safe diagnostic and repair sequence
- Run a timed request from the WordPress host and record DNS, connect and total time.
- Verify the destination certificate and redirects so the request is not looping.
- Set a bounded timeout appropriate to the operation and handle failure explicitly.
- Move non-critical background calls out of visitor requests where possible.
How to choose between the likely causes
Do not treat Remote service latency and DNS delay as interchangeable. The API or vendor endpoint is slow or unavailable. By contrast, the server cannot resolve the destination promptly or consistently. Use two checks to separate them: Capture the complete error, including URL and timeout duration; and test DNS resolution, TCP connection and HTTPS response separately from the server. Those observations usually show whether the next safe move is to run a timed request from the WordPress host and record DNS, connect and total time or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not set very high global HTTP timeouts. A failing dependency can then exhaust PHP workers and turn one integration issue into a site-wide outage.
How to verify the repair
- The external request completes within a predictable bounded time.
- Failure is handled without blocking page loads, checkout or cron.
- No new cURL 28 entries appear during a representative test window.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
This error often appears in Site Health, updates, payment gateways, licences, webhooks or remote APIs. Raising the timeout may hide a slow dependency while keeping PHP workers occupied for longer.
- 1
Capture the complete error, including URL and timeout duration.
- 2
Test DNS resolution, TCP connection and HTTPS response separately from the server.
- 3
Identify the plugin, theme or core operation that made the request.
- 4
Compare one failed request with a successful request from another network or host.
What must be verified
- The external request completes within a predictable bounded time.
- Failure is handled without blocking page loads, checkout or cron.
- No new cURL 28 entries appear during a representative test window.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Will simply raising the cURL timeout value fix this permanently?+
Raising the timeout can hide a genuinely slow dependency while keeping PHP workers occupied longer, which risks turning one slow integration into broader worker saturation. It is better to identify why the remote call is slow and set a timeout that matches the operation.
How can I tell if the problem is DNS, the connection, or the remote service's response time?+
Run a timed request from the WordPress server itself and measure DNS resolution, TCP connection, and total response time separately. Comparing that against a request from a different network or host shows whether the slowness is specific to your server's path or shared by everyone.
Could an outbound firewall cause this even if the destination service is healthy?+
Yes. Hosting or security rules that block a specific destination host or port produce the same timeout symptom as genuine remote latency. Testing DNS, connection, and HTTPS response separately from the server helps distinguish a blocked outbound path from a slow but reachable service.
Is this error likely to affect the whole site or just one feature?+
It typically affects only the specific operation making the outbound call — Site Health, an update check, a payment gateway, a licence check, or a webhook — not the site broadly. Moving non-critical background calls out of visitor-facing requests limits how far the impact spreads.