WordPress’s HTTP-based WP-Cron spawning kept failing with a cURL error 28, zero bytes received, no matter what was adjusted on the HTTP side. A controlled test confirmed PHP itself could run the WordPress cron file successfully when executed directly, outside of the failing HTTP self-request, returning a clean exit status.
⚡ Quick Fix (TL;DR)
The Culprit: The workload itself was fine — WordPress's cron logic ran correctly. It was specifically the HTTP self-request path that was unreliable, which meant there was already a proven, working alternative path available.
The Fix: WP-Cron's built-in HTTP spawning was disabled, and a server-level cron job was set up to run the same cron file directly through PHP every five minutes instead.
define( 'DISABLE_WP_CRON', true );
// Server cron entry (every 5 minutes):
/usr/local/bin/php /home/username/public_html/yoursite.com/wp-cron.phpRather not untangle this yourself? Our Done-For-You team handles exactly this kind of thing, start to finish.
See DFY options → Was this helpful? Thanks for the feedback!
Tagged in :