How to fix a 503 Service Unavailable error

A 503 Service Unavailable error means the server is up and answering, but it is telling you, deliberately, that it cannot handle the request right now. That is different from a 500, which means something broke, and different from a 502, which means a gateway got a bad response from behind it. A 503 is the server saying "not now" — usually because it is either intentionally in maintenance, or genuinely too busy.

Because of that wording, a 503 is one of the more reassuring errors to see: it implies the server is functioning well enough to issue a proper, deliberate response rather than failing outright. Most causes are temporary and several fix themselves.

The causes, in the order worth checking

1. A leftover maintenance file from a failed update

WordPress places a file called .maintenance in the site root while it updates itself or a plugin, and shows a "briefly unavailable for scheduled maintenance" 503 page while that file exists. If an update is interrupted — a lost connection, a timeout, a manual stop — the file can be left behind, and the site stays in maintenance mode indefinitely even though nothing is actually updating any more.

Open the file manager in your control panel and check the site root for a file named .maintenance (the leading dot may need hidden files switched on to see it). If it's there and no update is genuinely in progress, delete it and reload.

2. The server has run out of available capacity

Shared hosting accounts operate within resource limits — the number of PHP processes that can run at once being the most relevant one here. If every available process is busy, a new request has nothing to be handed to and receives a 503 rather than an indefinite wait. This is the load-related cause referenced above, and it explains why the error is often intermittent rather than constant.

Check the resource usage section of your control panel. A spike in active processes or CPU usage around the time of the errors points here, and the next question is what's driving it — a genuine traffic increase, or a single script or plugin consuming far more than its share.

3. A plugin or script is generating far more load than normal

A single badly written plugin, a runaway cron job, or a script stuck in a loop can consume enough resources on its own to push a site into the state described above, even with ordinary visitor traffic. Deactivating recently installed or updated plugins and observing whether the load drops is the fastest way to confirm this.

4. Real traffic has genuinely exceeded what the plan allows

If the timing lines up with a traffic event — a promotion, a piece of press coverage, a social media post that took off — the honest explanation may be that the current hosting plan's resource allowance is being exceeded by legitimate demand. This is worth distinguishing clearly from a bug, because the fix is different: either reducing the load the site itself generates per visit, or moving to a plan with a higher resource ceiling.

5. A platform-side issue on the hosting infrastructure

Least likely, but worth checking if a 503 affects multiple unrelated sites on the same account or the same server at the same time, with nothing having changed on any of them. This is the one genuinely platform-side cause on this list, and it is worth reporting rather than debugging further, since there is nothing in your own files to fix in that case.

Finding the specific cause in the log

The error log section of your control panel will show what was happening at the exact time of the 503 — a resource limit being hit, a process being killed, or nothing at all, which itself is informative because an empty log at that timestamp points more towards the platform than towards your own code.

If it keeps recurring

Note whether the 503s cluster around a specific time of day, a specific page, or a specific action such as saving a large post or running an import. That pattern, along with the exact timestamps, is what lets support match your report against server-side resource logs and tell you definitively whether this is a load ceiling worth raising or a script worth fixing.