adminNginx 504 Gateway Timeout Deep Diagnosis Checklist
Nginx 504 Gateway Timeout means the upstream service did not respond in time. The backend may be slow, overloaded, blocked by database queries, stuck in PHP execution or waiting for an external API.
Core principle
504 is a time problem. Nginx can reach the backend, but the backend cannot finish the work fast enough.
Checklist
- Identify the URL or action causing timeout.
- Check whether all pages timeout or only specific actions.
- Check Nginx error log for upstream timeout messages.
- Check PHP-FPM or backend logs.
- Check CPU, RAM and disk pressure.
- Check MySQL load or slow queries.
- Check long-running imports, backups or cron jobs.
- Check external API calls if the app depends on them.
- Increase timeout only after understanding the root cause.
- Verify response time after mitigation.
Reusable lesson
This applies to WordPress imports, WooCommerce checkout, heavy admin pages, APIs, n8n workflows, crawlers and automation endpoints.
When to Use This Checklist
Use this checklist when Nginx returns 504 during WordPress actions, imports, admin pages, APIs, webhooks or automation workflows.
Required Tools
SSH access, Nginx logs, PHP-FPM logs, MySQL access, server monitoring, affected URL or action
Before You Start
Do not simply raise timeouts. First find why the backend takes too long.
Structured Checklist Steps
- Identify timeout action.
- Check scope.
- Read Nginx logs.
- Read backend logs.
- Check CPU RAM disk.
- Check MySQL load.
- Check cron and imports.
- Check external APIs.
- Adjust timeout only if justified.
- Verify response time.
Verification Steps
- Timeout source is identified.
- Backend pressure is reduced or explained.
- Logs no longer show repeated timeout.
- Critical URL responds within acceptable time.
- Timeout changes are documented if used.
Rollback Plan
If timeout tuning hides the symptom but server pressure remains, restore safe timeout values and fix the slow backend operation in smaller batches.
Common Mistakes
- Increasing timeouts blindly.
- Ignoring database load.
- Running heavy imports during traffic.
- Not checking PHP-FPM workers.
- Confusing 504 with network DNS issue.
Related Commands
curl -w "%{time_total}
" -o /dev/null -s https://example.com
sudo tail -n 100 /var/log/nginx/error.log
sudo systemctl status php8.2-fpm
top
free -h
mysqladmin -u root -p processlist
crontab -l