A 503 status code reveals an issue that typically appears when the site’s server is not reachable. The 2 main reasons are that the server is down for maintenance or that is overloaded.

What is a 503 HTTP error code?

The Internet Engineering Task Force (IETF) defines the 503 Service Unavailable as:

 The 503 (Service Unavailable) status code indicates that *the server
 is currently unable to handle the request due to a temporary overload
 or scheduled maintenance*, which will likely be alleviated after some
 delay.  The server MAY send a Retry-After header field
 (Section 7.1.3) to suggest an appropriate amount of time for the
 client to wait before retrying the request.

Lack of server resources

The server has reached its full CPU capacity and is throttling, becoming unable to run the website or API. Learning how to monitor CPU usage on Linux tells you whether the box was actually saturated or just waiting on disk. It might be a good idea to setup server monitoring, such as Netdata, which is free, or a hosted agent if you would rather not run your own stack (we compare both in our Netdata alternative breakdown).

The surest way to fix a 503 error is to increase your server's capacity. You can do this by upgrading your hosting plan, or if you have a virtual server, you will have to upgrade the machine itself. This can be done easily with one click in your web hosting dashboard.

Shared server machine

Most of the time, these errors are occasional, mostly due to hardware errors on the server side, like a false positive. In a lot of providers, such as DigitalOcean, GoDaddy or Hostinger, your website are hosted on virtual machines that share resources from the same physical server. Other users using a lot of the machine's resource could potentially cause your website a 503 HTTP error. Generally due by a peak of traffic from users, or periodic jobs processing heavy loads, such as database backups. Monitoring the VPS itself is the fastest way to tell whether your own workload was eating CPU and memory at the time, or whether the machine was already busy before your traffic arrived. To avoid risking such issue, it is recommended to use bare-metal servers, which are physical servers dedicated to a single tenant.

Use caching

Another way to increase your server resources is through caching - this method makes it easier for users to quickly access files on your site because they take up less space on the server. This has the added bonus of lowering bandwidth costs and increasing website speed and performance for users (and thus increasing conversions). To implement caching, there are either software solutions like W3 Total Cache and WP Super Cache or services which will cache pages for you like CloudFlare or Akamai.

Your application has crashed

Your application may have crashed. Check the event viewer and see if you can find event logs in your Application/System log, then try restarting your server application.

The service is down for maintenance

Most web servers shut down during maintenance. If you can access your server's administration settings, check the configuration options to see when automatic maintenance sessions are scheduled. You can also disable these automatic updates in the configuration options if you would rather have complete control over your server's maintenance schedule.

The website you're trying to reach is probably handling a status page, where they share real time updates about their ongoing issues and maintenance updates.

503 Service Temporarily Unavailable (nginx ingress)

On Kubernetes, the ingress-nginx controller answers 503 Service Temporarily Unavailable, on a bare HTML page signed nginx, when the Service behind an Ingress has no ready endpoint. (Upstream ingress-nginx was retired in March 2026 and gets no new releases as of October 2026, but it still runs in a lot of clusters.)

Cause. No pod behind the Service is Ready: the Service selector does not match the pod labels, the readiness probe fails, the pods are crash-looping (an OOMKilled container is a common one), or the deployment was scaled to zero.

Confirm it.

kubectl get endpointslices -n shop -l kubernetes.io/service-name=checkout
kubectl get pods -n shop -l app=checkout
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller | grep "does not have any active Endpoint"

An EndpointSlice with no ready address, pods stuck at 0/1 READY, or a controller line such as Service "shop/checkout" does not have any active Endpoint all point to the same cause.

Fix it. Compare the selector in kubectl describe svc checkout with the pod labels, then read kubectl describe pod for failed readiness probes or the last termination reason. As soon as one pod is Ready, the controller routes to it again, with no restart needed. If the endpoints exist but the pods refuse or drop connections, the controller returns a 502 instead, and its log shows connect() failed (111: Connection refused) or upstream prematurely closed connection.

What would have warned you. An HTTP monitor on a URL served through the Ingress, with 200 as the expected status code, fails on the first 503. Hyperping reruns the check from your other regions at once and opens an outage only if they see the 503 too, which a cluster-side problem like this one always produces.

Target group unhealthy

On an AWS Application Load Balancer, the 503 has a narrow cause: the target group that the listener rule forwards to has no registered targets, or every registered target is unused (stopped, terminated, or in an Availability Zone the load balancer does not have enabled). The console shows those targets as unused, or the target group as empty, with reason codes such as Target.NotRegistered, Target.NotInUse or Target.InvalidState.

One detail changes the diagnosis. Unhealthy targets, with reason codes such as Target.ResponseCodeMismatch ("Health checks failed with these codes: [503]") or Target.Timeout, do not produce the 503. When every registered target fails its health checks, the ALB fails open and keeps sending traffic to all of them, so visitors get the targets' own errors, often a 502 or a 504, rather than a 503 from the load balancer (AWS documentation, as of October 2026). A 503 generated by the ALB means nothing is registered or usable. For the 502 side, see ALB 502 Bad Gateway.

Confirm it.

aws elbv2 describe-target-health --target-group-arn <target-group-arn> \
  --query 'TargetHealthDescriptions[].[Target.Id,TargetHealth.State,TargetHealth.Reason,TargetHealth.Description]' \
  --output table

In CloudWatch, a rising HTTPCode_ELB_503_Count with a flat HTTPCode_Target_5XX_Count confirms that the load balancer, not your application, produced the 503. From a host inside the VPC, curl -i http://<target-private-ip>:<port>/health shows exactly what the health check receives.

Fix it. No registered targets usually means an Auto Scaling group or ECS service at zero tasks, or a target group that is not attached to it: check the desired count and the attached target groups. For Target.ResponseCodeMismatch, the health check path answers something other than the success codes (200 by default), often a redirect to HTTPS or a 401: point the check at a path that returns 200, or widen the success codes. For Target.Timeout, the targets' security group must allow the load balancer's security group on the health check port.

What would have warned you. Your targets sit in private subnets, so watch what customers reach: an HTTP monitor on the public hostname with 200 as the expected status code, checked from several regions. It catches the ALB's 503 and the 502 or 504 of a fail-open alike.

503 ERROR: The request could not be satisfied (CloudFront)

This is CloudFront's own error page. It has three common causes, per the AWS documentation as of October 2026:

  • The origin returned the 503 and CloudFront relayed it. An S3 origin throttles above 5,500 GET or HEAD requests per second per prefix (it answers 503 Slow Down), an ALB origin has no usable target (see the section above), or an EC2 or custom origin is out of CPU or memory.
  • A Lambda@Edge or CloudFront Functions error, or Lambda@Edge throttled by its concurrency or invocation quotas.
  • Edge capacity, rarely, mostly during load tests that ignore CloudFront's load testing guidelines.

Less often, an origin configured with mutual TLS that keeps failing its handshakes makes CloudFront return a 503 too.

Confirm it.

curl -sI https://www.example.com/ | grep -iE '^(HTTP|x-cache|x-amz-cf-pop)'
curl -sI https://origin.example.com/ | head -1

A 503 with x-cache: Error from cloudfront while the origin answers 200 directly points at a function or the edge: read the function's logs in CloudWatch. A 503 from the origin as well means the origin is the problem.

Fix it. Scale the origin, or spread S3 objects across more prefixes so the request rate splits. Fix the function error, or request a higher Lambda quota if it is throttled. Follow CloudFront's load testing guidelines before the next test.

What would have warned you. An HTTP monitor on the CloudFront hostname with 200 as the expected status code, plus a second one on the origin hostname, tells you which layer failed at a glance. If the origin is exposed directly, a TCP port monitor on 443 separates "the origin refuses connections" from "the origin answers 503". A failure seen from a single region does not open an outage, since the other regions recheck it, but it stays in the monitor's logs, which is how a single edge location in trouble shows up.

More gateway messages, from nginx and AWS, are listed in our error reference.

Wordpress related 503s

WordPress powers more than 30% of web servers, making it the most popular CMS on the internet. If you're running a WordPress site, then you know how frustrating server issues can be. One of the most common errors is HTTP Error 503 Service Unavailable. Fortunately, there are many easy fixes for this error. Here are some ways to fix the HTTP Error 503 Service Unavailable in WordPress so your site stays up and running 24/7. Solutions listed above could help solve your 503 HTTP error, but some issues are specific to Wordpress applications:

Misconfigured applications

Misconfigured web apps may also cause a 503 error to appear, such as a plugin conflict caused by WordPress. The 503 service unavailable error occurs when your web server is unable to get a proper response from a PHP script. This PHP script could be a WordPress plugin, a theme, or a misbehaving custom code snippet.

Deactivate all Wordpress plugins

Try disabling all Wordpress plugins, see if this solves the issue, then switch them back on one by one to pin-point which one was causing your website an error.

One simple method is emptying your Plugins folder to a another temporary folder. Then proceed by moving plugins one by one to your Plugins folder, until you face the error again. You could either re-install the plugin that was causing the error, find an alternative plugin, or see the next solution.

Update or revert Wordpress's PHP versions or your plugins or theme

You might encounter a 503 Service Unavailable after your updated your plugins. She of the newer plugins don’t work as well with older versions of PHP. Log-in to CPANEL and change back the PHP version to a lower version.

Another solution would be to uninstall your theme to reinstall it with its latest version.

If these methods fail to resolve the error, then try contacting your hosting provider.

Increase WP Memory Limit

Raising the PHP limit only helps if the machine still has memory to give, so check first with our guide on how to monitor memory usage on Linux. You need to paste this code in wp-config.php file just before the line that says 'That’s all, stop editing! Happy blogging.'

define( ‘WP_MEMORY_LIMIT’, ‘256M’ );

Once you are done, you need to save your changes and upload your wp-config.php file back to your server.

Disable SSL

Before you do a clean install, try disabling your SSL settings in your hosting or plugins.

Change your hosting provider

If you're facing too many 503 HTTP error codes, try changing your hosting provider to one more reliable. GoDaddy, Hostinger or BlueHost are great alternatives.

How to prevent 503 HTTP errors from happening?

Most 503 HTTP error codes could go unnoticed, as you're not browsing your site 24/7.

A great way to monitor these errors is to use an Uptime Monitoring service. They will ping your Wordpress site every 30 seconds, and will send you alerts via email, SMS or Slack, and show you reports when facing 503 HTTP error codes, or any other issues. This way you'll stay aware of any problems your Wordpress sites might encounter, and you'll be able to react faster.

Uptime checks tell you the site went down, but not why. Watching CPU, memory and filesystem usage catches the saturation that produces 503s, usually a few minutes before visitors see one. Our guide on where to set server monitoring alert thresholds covers the numbers worth alerting on in your own alerting layer.