503 Service Unavailable error

The 503 Service Unavailable error means the service can't handle the request at that moment. It may be temporary, but you need to identify where it comes from before changing the configuration.

The code is generic. Before changing resources or PHP, save the URL, time, body and headers of a single response and check the web, PHP and application logs for that same moment. The page content may reveal whether the 503 was generated by the application, a maintenance mode, a proxy or the server.

Resource usage exceeded

Every hosting service has a set of allocated resources: CPU, RAM and number of simultaneous processes.

These limits help isolate usage between accounts on the server. They aren't the same as having a dedicated physical machine, nor do they rule out a shared incident.

Not every limit produces a 503. On CloudLinux, CPU and I/O usually slow the account down; the entry process limit usually produces a 508; memory or the number of processes can end in a 500, a 503 or killed processes. Check the LVE fault counters for the same interval before blaming the code on resources.

cPanel lets you debug resource usage and take snapshots of the processes causing it, which gives you key information for finding the cause.

Snapshots show active processes and requests, but they don't guarantee the cause. In WordPress or Drupal they may point to index.php because it is the front controller; in that case, correlate the URL with the log and the application's profiling.

Causes worth checking against the logs include:

• Poorly performing or faulty plugins or themes: isolate the component only after gathering evidence, with a reversible test and preferably in staging, or with maintenance mode and a backup available. Don't indiscriminately disable every component in production.
• Lack of optimisation: a website may work normally and quickly with few visitors but create a "bottleneck" once more simultaneous visits start coming in. This is because each process uses a large amount of resources; the solution is to analyse and optimise your applications to reduce resource usage, which will in turn improve loading speed.
• If the failures start after a plugin or app update, check the new version's requirements to adjust PHP versions, modules and configuration; if they are correct, ask the developer whether there is a bug in that update. If you need to roll back, check the date and availability of a backup.

Ultimately, if your app is as optimised as it can be, it may simply be that the project has grown and needs more resources. You can switch to a higher plan to get a larger CPU and memory allocation, or contact us to look at your needs.

Application, maintenance or backend

Check whether the application has turned on a maintenance mode or generates its own 503. If the log identifies PHP-FPM, LSAPI or an unavailable backend, review that service. Change the PHP version or modules only when the exact error or the application's requirements prove an incompatibility; you can adjust the PHP configuration once it is confirmed.

Internal system problem

If the logs and metrics don't reveal the source, contact support with the URL, time, exact response and steps to reproduce it.

Check the recovery

Repeat an equivalent request and check the status code, the content and the metrics. In a shop, the home page loading again doesn't confirm that the cart or payment work. If you are considering a restore, first keep any orders, messages or changes made after the backup and plan how to reconcile them.

If the 503 comes from planned maintenance, check how long it lasts and what response users and search engines get. Avoid leaving the website in that state indefinitely. A higher plan makes sense when the metrics confirm a lack of capacity; it doesn't fix a code exception or a wrong redirect.