cURL error 28 means a server-side network operation reached its allowed timeout. The rest of your website can work while one plugin cannot contact an external API or your own site.
Start with the destination and complete message, then compare DNS, connection and response timing from the hosting server.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Pattern | Investigation | Next check |
|---|---|---|
| Only one external service fails | Destination or integration path | Provider status and a redacted endpoint. |
| Several unrelated services fail | Hosting network or configuration | Server-side DNS and HTTPS tests. |
| Request targets your own domain | Loopback access and worker availability | Site Health plus matching logs. |
| Timeout follows a data-changing request | Remote result may exist | Check records before retrying. |
Keep the complete timeout message
Report the stage: a message about name resolution differs from one about an established connection receiving no reply. Keep the specified milliseconds and destination hostname. Those details help the host decide which test to run.
Copy the error text and note the time it happened. A message that mentions a resolving timeout points toward a different stage from a message saying the connection was established but no response arrived. The number of milliseconds tells you how long that particular operation was allowed to wait.
The destination URL is useful, but it can contain a license key, API token, or private query parameter. Remove those details before sharing it in a public forum. Your host usually needs the destination hostname, approximate time, and the redacted error to begin a connectivity check.
If the error appeared during checkout or another transaction, check the service’s own records before repeating the action. A timeout does not prove the remote service rejected the request. It may have accepted the action while the reply was delayed.
Compare one destination with others
- Record one controlled failed operation.
- Compare an unrelated supported server request.
- Ask the host to test the failing destination from the server.
- Match the test with connectivity or application logs before changing timeout settings.
Look at the plugin’s status screen and Tools → Site Health. If only one service fails, check that service’s status and the integration’s settings. If unrelated update checks and API calls fail together, your hosting network or server configuration becomes a stronger possibility.
Opening the destination in your browser is a useful comparison, but your computer and the WordPress server use different networks. A page that opens on your laptop can still be unreachable from the host. Ask the hosting provider to test DNS resolution and HTTPS connectivity from the server itself.
The provider can also check whether the connection uses an unexpected IP address, whether IPv4 and IPv6 behave differently, and whether an outbound firewall rule affects the destination. These checks are more informative than repeatedly retrying the same plugin operation.
When WordPress is calling its own site
A loopback request travels from your server to your own site address. It can be affected by password protection, a firewall challenge, redirects, or the way the domain resolves from the server. A security page intended for human visitors may not be answerable by an automated request.
Use the exact Site Health warning as a guide. A publicly accessible API index does not prove that every authenticated REST request or scheduled task works. Our REST API troubleshooting guide covers those distinctions, while the WP-Cron guide follows missed background tasks.
Rather than turning off all security, match the failed request with the firewall’s logs. A narrow exception for a verified internal request may be appropriate; the relevant provider can help decide what is needed. On a password-protected staging site, an expected loopback restriction may not represent a production failure.
Check whether the server has time to respond
A busy server can delay its own loopback responses. If PHP workers are occupied by long-running jobs, another internal request may sit waiting for an available worker. Compare the error time with CPU use, worker activity, and any other slow requests.
For an external API, review how much data the plugin sends and whether it retries requests in a loop. A batch export that fails halfway through may benefit from smaller batches. A license check that should finish quickly needs a destination or connectivity investigation instead.
The integration may have its own timeout setting. A modest extension can help a service that is reliably slow, but will not fix a blocked connection or an unavailable endpoint. The libcurl timeout is also separate from PHP’s execution limit and from a gateway’s response deadline.
Test the feature that originally failed
After the repair, repeat one controlled request and review both sides of the exchange where possible. A cleared Site Health warning is helpful, but a backup integration should also transfer a file successfully, and an update check should return usable version information.
Keep the destination, cause, and successful test in your notes. If the problem returns, those details make it much easier to compare incidents. The official libcurl error reference identifies code 28 as an operation timeout; the surrounding message and server evidence explain which part of your request needs attention.
Confirm the original integration works
Repeat one controlled operation and inspect the destination’s result where available. Check for duplicate records from prior timed-out attempts. Record the failed stage and corrected path; a browser visit from your computer cannot establish server connectivity.