503 Service Unavailable: site under maintenance, server full, or provider outage?

What it means, in a nutshell

The server received the request but can't respond right now: it's not a connectivity problem on the visitor's end, it's the server (or something upstream) temporarily refusing to do the work.

The fastest check (30 seconds)

Before digging into logs or control panels, open the site from another device or on mobile data, not from the same network you're on. If it responds from there but not from the browser you normally use, the problem is a local cache or a corporate proxy, not the server. If the 503 shows up everywhere, move on to the three causes below, in the order they tend to occur most often.

1) Maintenance mode left switched on (the most common case on WordPress)

How to spot it: the site shows the "Briefly unavailable for scheduled maintenance" page, or stays blank after a plugin or core update was interrupted (tab closed, connection dropped, timeout). The cause is almost always a hidden file called .maintenance in the WordPress root folder, which the CMS creates automatically during updates and should remove on its own once the job finishes.

How to fix it, on Ubuntu 24.04 via SSH (applies to any hosting where you have shell access):

cd /var/www/tuosito.it/public_html
ls -la | grep maintenance
rm .maintenance

cPanel alternative: File Manager → go to the public_html folder (or the domain's folder if it's an addon domain) → Settings → tick "Show Hidden Files (dotfiles)" → find .maintenance → Delete. Plesk alternative: File Manager → same procedure, showing hidden files.

WP-CLI alternative, if installed: wp maintenance-mode deactivate, which removes the .maintenance file and brings the site back online immediately.

Deleting the file is a safe operation: removing .maintenance is harmless, as WordPress will recreate it whenever needed during a future update. If the update had stopped halfway through, after removing the file check in wp-admin → Dashboard → Updates that the plugin or core shows as correctly installed; if not, re-run the update before considering the issue closed.

How to confirm it's fixed: reload the site in a private/incognito browser window. If the 503 comes back, the file has been recreated: this means something (a plugin, a cron job, a hung call) is regenerating maintenance mode, and the next step is to disable plugins by renaming the wp-content/plugins folder via SSH or FTP, to isolate which one is blocking the exit from maintenance mode.

2) Process or memory limit reached (shared hosting and VPS with PHP-FPM)

How to spot it, on Ubuntu 24.04 with Nginx and PHP-FPM: open the Nginx log with

sudo tail -n 50 /var/log/nginx/error.log

That's the default path on Ubuntu and Debian according to Nginx's official documentation, which states that on RHEL-based systems, Debian and Ubuntu the path is /var/log/nginx/error.log. The line that matters is the one showing a connection error to the PHP-FPM socket: if you see a message saying the connection failed because a resource was temporarily unavailable, the PHP-FPM pool has reached the maximum number of configured processes (pm.max_children) and is rejecting new requests.

Check the configured value with:

sudo grep max_children /etc/php/8.3/fpm/pool.d/www.conf

and the service status with sudo systemctl status php8.3-fpm. A 503 of this kind often coincides with a traffic spike or a process that won't close (a slow cron job, a plugin running heavy queries).

How to fix it: as an immediate measure, a restart frees up the stuck processes: sudo systemctl restart php8.3-fpm. In the medium term, pm.max_children should only be increased if the available RAM allows it (every PHP process uses real memory: raising the number without checking RAM just shifts the problem from a 503 to an OOM kill, i.e. the kernel killing processes due to lack of memory), or else you need to find and fix whatever is keeping the processes busy longer than it should.

cPanel alternative: the equivalent log is Apache's, which according to the documentation from providers running cPanel servers is typically found at /usr/local/apache/logs/error_log, where all Apache errors are logged, regardless of the site. From there, look for lines containing "PHP Fatal" or references to suPHP/php-fpm around the time of the outage.

How to confirm it's fixed: reload the site's heaviest page (usually the homepage or a page with many queries) several times in quick succession; if the 503 doesn't return, the pool is coping with the current load.

3) An upstream fault: out of your hands

If the site is unreachable from different networks, the control panel itself won't load, or the provider has posted a notice on its status page, the problem lies upstream: load balancer, CDN, or the physical node your hosting runs on. In this case, there's no local command that will fix it, because you don't have access to the root cause.

What to attach to the support ticket, to avoid wasting time going back and forth:

• the exact time (with time zone) you noticed the problem;
• your hosting's IP address, which you can get with nslookup tuosito.it;
• the output of curl -I https://tuosito.it, which shows the response code and the headers received;
• if possible, the output of a traceroute tuosito.it to show where the request stalls.

Summary: where to look depending on your control panel

Panel	File/log to check first	Path
None, SSH on Ubuntu+Nginx+PHP-FPM	Nginx error log	/var/log/nginx/error.log
cPanel	Apache error log	/usr/local/apache/logs/error_log
Plesk	Domain error log	File Manager → Logs, or Statistics → Error Log
Any panel, if WordPress	Maintenance file	.maintenance in the site root

None of these checks takes more than a few minutes: the order in which you perform them (maintenance mode, then processes, then external fault) also reflects the order of likelihood on a shared hosting account or a small, manually managed VPS.