WordPress cron requests returning 502

How WordPress cron fails with a 502

WordPress does not run a real operating-system scheduler. When someone visits the site, wp-cron.php runs at the request edges and processes events that are "due". Each visit can trigger a run of overdue jobs in that same HTTP request. That is the key fact for a 502: the visitor's request is also the cron worker, so a slow job can push the whole request past the gateway timeout (nginx timeout 60, or the PHP-FPM request_terminate_timeout), and the upstream returns 502 for the page and every cron job it tried to run.

Signs you are dealing with cron 502s

• The error log shows wp-cron.php lines with 502 beside them while the front page is fine.
• GET /wp-cron.php returns 502 or a 504 Gateway Timeout when called manually.
• A plugin reports "Scheduled event did not run" for every event due.
• The 502 appears specifically right after the double-digit second mark, which is the point the gateway timeout fires.

Because cron is fired by visitors, a site with low traffic can go for days between successful runs, then throw a pile of jobs at one unlucky request and 502 only at that moment. The failure is a schedule, not a page.

Find the failing job

1. Lock the log window: add a marker to see the request edge, or view the PHP-FPM slow-log which already records requests that exceed request.slowlog_timeout.
2. Check the events queue from WP-CLI:

wp cron event list --status=due --fields=hook,schedule,next_run_relative

1. Identify which hooks fire at the failing time. The usual suspects are long HTTP drives inside a cron event: an external API fetch, a large email blast, an image resize loop, or a plugin health-check that calls an API endpoint per site.
2. Confirm the timeout value in your stack so you know what "too slow" means here: max_execution_time for PHP, request_terminate_timeout for PHP-FPM, and the gateway timeout for nginx.

Fix the batch

1. Spread the load. wp config set DISABLE_WP_CRON true --raw and add a real system cron that hits wp-cron.php at 5-minute intervals with curl --max-time 55. Then fast requests stop mounting.
2. Raise the right timeout for the job, not the site. If a rebuild job needs 300 seconds, raise the PHP maximum for the CLI job only; do not set the web max_execution_time to 300. For media-heavy jobs, wp media regenerate from CLI is the safe route instead of the in-browser AJAX.
3. Split the job. Break a giant loop into an event that re-queues itself (wp_schedule_single_event) per chunk, so each run stays well under the timeout.
4. Plug memory leaks. A 502 during cron frequently sits next to memory_limit exhaustion in the log; the loop that failed is the loop that grows. Fix that first, then raise memory.
5. Verify in isolation. wp cron event run <hook> runs exactly one event and returns before the gateway; then retest with a curl against wp-cron.php.

Prevention

• Real OS cron (DISABLE_WP_CRON) with --max-time, so visitors never time out.
• A monitoring alert on the exact phrase wp-cron.php in the access log returning 502.
• Keep one health check site in place and note scheduled event drift (see the headless cron troubleshooting guide).

The 502 error overview is the broader path to the same gateway limit, and the 504 walkthrough explains the upstream timeout that a slow cron run trips.