Magento 2 503 Service Unavailable: Causes and How to Fix It

A 503 on Magento is one of the more alarming errors you can hit, mostly because it tells you almost nothing — your whole store is down, and the page itself gives no clue why. Here's how to actually find and fix the cause.

Check Maintenance Mode First

The single most common cause of a "surprise" 503 is maintenance mode left on after a deployment.

bin/magento maintenance:status

If it's enabled:

bin/magento maintenance:disable

If your deploy script sets maintenance mode automatically, make sure the step that disables it afterward is actually running — a failed deployment step earlier in the pipeline can leave the site stuck in maintenance with no error to point at.

Check PHP-FPM and Web Server Timeouts

If a request takes longer than your web server or PHP-FPM is configured to wait, you'll get a 503 instead of a slow page. This shows up most often during large imports, reindexing, or checkout under load.

Nginx:

fastcgi_read_timeout 600;
proxy_read_timeout 600;

PHP-FPM pool config:

request_terminate_timeout = 600

php.ini:

max_execution_time = 600
memory_limit = 2G

Don't just raise these blindly forever — a request that legitimately takes 10 minutes is usually a sign something else (an unindexed query, an N+1 API call) needs fixing, not just more time.

Check PHP-FPM's max_children

If PHP-FPM runs out of available worker processes, new requests queue up and eventually time out as 503s — this looks exactly like a "site is slow then dies" pattern under traffic spikes.

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

Check how close you are to the limit right now:

sudo systemctl status php8.2-fpm

If you're consistently near max_children, that's a capacity problem, not a config typo — you either need more workers (and the RAM to back them) or you need to find what's holding requests open too long.

Read the Actual Logs

Skipping straight to logs saves time over guessing:

tail -f var/log/exception.log
tail -f var/log/system.log
tail -f /var/log/nginx/error.log
tail -f /var/log/php8.2-fpm.log

A 503 with nothing in exception.log almost always means the request never reached Magento's PHP layer at all — the problem is in Nginx, PHP-FPM, or a memory/timeout limit upstream of the application.

Quick Checklist

1. Confirm maintenance mode is actually off.
2. Check PHP-FPM and web server timeout settings against how long the failing request realistically takes.
3. Check pm.max_children against actual traffic — is FPM starved for workers?
4. Check memory_limit — a fatal "Allowed memory size exhausted" error sometimes surfaces as a 503 rather than a visible PHP error, depending on your error display settings.
5. Tail all four logs above during a reproduction, not after.

A 503 is rarely one single universal cause — it's whichever layer between the browser and Magento decided to give up first. Working through this list in order will find it faster than guessing at the config file that "usually" fixes it.