503 Service Unavailable Error: What It Means and How to Fix It

What is a 503 Service Unavailable error?

A 503 Service Unavailable error is an HTTP status code. It means the server cannot handle your request right now. In most cases the server is running, but it is overloaded, under maintenance, or out of resources. Because the condition is meant to be temporary, a short wait often fixes it.

This code belongs to the 5xx family of server errors. With 4xx codes, the problem usually sits in the request. With 5xx codes, however, the problem sits on the server side. MDN describes a 503 response as the server not being ready to handle the request. You can read the primary sources on the MDN 503 page and in the RFC 9110 section on 503.

Also, browsers and hosts word the message in different ways. For example, you may see "Service Unavailable", "HTTP Error 503", "Service Temporarily Unavailable", or a branded maintenance page. Still, the status code underneath stays the same.

This guide serves three readers. First, if you are a visitor, you will learn what to try. Second, if you own the site, you will learn what to check first. Finally, if you run your own VPS, you will get commands for a proper diagnosis. In addition, we explain why a 503 is the right answer during maintenance, which matters for SEO.

Who is responsible for a 503 Service Unavailable error: the visitor, the site owner, or the server admin?

If you are the visitor, the error is not your fault, because it starts on the server. In fact, the people who can fix it are the site owner and the server administrator. Still, each role can do something useful. Work out your own role first, since chasing the wrong cause only prolongs the outage.

If you reach the site owner, report the problem. Also, if you buy hosting from a provider, that provider has the final say on resource limits. Therefore the graphs in your hosting panel are your best evidence.

What causes a 503 Service Unavailable error?

The error appears when the server cannot process a request at that moment. The causes fall into a few groups. For example, below are the most common ones, and later sections show how to diagnose each of them.

• The server or its PHP workers are overloaded and cannot queue another request.
• Your hosting plan reaches its CPU, memory, or concurrent process limit.
• The site sits in maintenance mode, on purpose or by accident.
• Bots, crawlers, or attack traffic use up the resources.
• The database, PHP-FPM, or another backend service crashes or stops responding.
• One bad plugin, theme, or update locks up the whole application.
• A reverse proxy or load balancer marks the backend as unhealthy.

In practice, the first two causes show up more often on shared hosting. Meanwhile, the last two show up more often on VPS and dedicated servers. However, the line is not strict. The same symptom can come from different root causes, so measure before you guess.

How do overload and hosting resource limits trigger a 503 Service Unavailable error?

First, every hosting plan sets limits for CPU, memory, and concurrent processes. When more requests arrive than the plan allows, the server turns new ones away. Visitors then see a 503, because the server is alive but cannot accept more work.

MDN also lists reached thresholds, such as memory, CPU, and connection pool limits, among the causes of a 503. On shared hosting, a busy neighbor can sometimes affect you. However, modern plans isolate accounts from each other. We explain how that isolation works in our CageFS guide.

For example, campaign days are the classic case. When an ad or an email sends a burst of visitors and pages do not come from a cache, every visit runs PHP and database queries. Within minutes the limit fills up, and then the 503 begins. Your ad budget keeps burning, because clicks arrive but pages do not load.

In addition, bandwidth is a separate limit. If your monthly transfer quota runs out, some providers suspend the site. We cover this in our guide to hosting bandwidth, so here we only suggest adding it to your checklist.

Can maintenance mode and updates cause a 503 Service Unavailable error?

Yes, and often it is on purpose, because it protects visitors from a half-updated site. Many systems switch the site into a short maintenance mode during updates and return a 503. However, the trouble starts when the exit from maintenance mode never finishes.

During a core update, WordPress creates a temporary .maintenance file in the site root. If the update stops halfway, that file can stay behind, and the site keeps showing a maintenance message. So deleting the file in your file manager usually fixes it. First, though, find out why the update stopped.

Updates usually stop for one of these reasons:

• The PHP time limit or memory limit was too low for the update.
• The connection dropped during a plugin update.
• The disk filled up, so files could not be written.
• A firewall blocked the update request.

Also, a backup before every update shrinks this risk. For a backup plan, read our website backup strategy guide.

Does bot and DDoS traffic produce a 503 Service Unavailable error?

It can. A botnet or a badly tuned crawler may send hundreds of requests within seconds, and the server runs out of resources. Real visitors then get the 503 too. Therefore the problem sits in the traffic, not in your code.

First, confirm that the traffic is really hostile. For example, in the access log, a flood of requests from one IP or a small IP block is a strong hint. That said, a legitimate search engine bot can also crawl heavily. We show how to verify Googlebot in our Googlebot guide.

You can defend in layers:

• Rate limiting rules and tools that block abusive IPs automatically
• Web application firewall rules
• Network-level absorption and distributed infrastructure

For the first layer, see our guides to Fail2ban and the CSF firewall. For the application layer, read about ModSecurity. For the network layer, our Anycast DNS guide is a good start.

How do you diagnose a 503 Service Unavailable error step by step?

Diagnose in order, because each step narrows the next one. First, find out whether everyone sees the error or only you. Then move to the server side.

1. Open the site from another network and another device, then check whether the error is global.
2. Then test outside access with an is it down checker.
3. Open the resource usage graph in your hosting panel and check whether CPU, memory, or the process limit is full.
4. Next, read the error log and look for repeating lines.
5. Think about the last change: a plugin, a theme, an update, or a new campaign.
6. Check whether a maintenance file or setting is still active.
7. Review bot traffic in the access log.

Keeping this order saves time, because each step cuts the search area. In most cases, one of the first three steps points to the cause. Remembering the last change helps more than you would expect, because most 503 problems start right after an update or a traffic spike.

What should you do as a visitor who gets a 503 error?

Your options are limited, because the fault is on the server. Still, a few simple steps can help. First, wait a few minutes and reload the page. Because short overloads often clear on their own, patience is a real fix.

• First, reload the page and try again after a minute or two.
• Open the same site on mobile data to rule out your own network.
• Try another page to see whether the whole site or a single page is affected.
• If you are shopping, do not hammer the reload button at checkout, because you risk a double charge.
• If the problem lasts, tell the site owner by phone or on social media.

Clearing the browser cache rarely fixes a 503, because the error comes from the server and not from your browser. Even so, an old error page can get stuck, so a hard refresh does no harm.

How do you fix a 503 Service Unavailable error as a site owner?

The fix depends on the cause, so follow the order of diagnosis first and action second. The table below sums up the common causes and the first response.

If you suspect a plugin, disable plugins one by one. That way, you find the culprit. Also, if you have a backup, going back to the last working version is the fastest exit. So always take a fresh backup before you try this.

How does a 503 Service Unavailable error show up on a WordPress site?

On WordPress, a 503 usually comes from one of three sources: an unfinished update, a heavy plugin, or a full PHP process limit. It tends to appear after an update or when traffic grows. If you can still reach the dashboard, inspect your plugins first.

If you cannot log in, use the file manager or FTP, open the wp-content folder, and temporarily rename the plugins folder. That disables every plugin. Then, if the site comes back, a plugin is the culprit. Rename the folder back, then reactivate plugins one at a time to find the one that causes the problem.

If the site still fails, look at the theme and the core update. Also delete a leftover maintenance file. If the error log shows a memory limit message, try raising the PHP memory limit in your hosting panel. Your provider sets the upper bound, so open a support ticket when the value will not change.

Heavy plugins such as WooCommerce cannot use page caching on cart and checkout pages. Therefore those pages burn more CPU. For that reason, review your resource limit before every campaign if you run a shop.

How does a 503 Service Unavailable error hurt ad spend and sales in e-commerce?

In e-commerce, a 503 is direct revenue loss, because every failed visit is a lost chance to sell. A shopper clicks your ad, but the page does not load. You pay for the click, so the shopper goes to a competitor at your expense. An error at the cart or checkout step costs even more.

For example, here is a simple calculation. Say you get 500 clicks a day at 1.50 USD per click. If the site fails for one hour, and that hour carries one twentieth of the daily traffic, about 25 clicks are wasted, or roughly 37.50 USD. The numbers are only an illustration, but the logic holds: multiply the outage length by the ad intensity.

As a precaution, first run a load test before a campaign starts, switch on caching, and set up monitoring alerts. In addition, raise the ad budget step by step instead of all at once. That gives the server time to adjust to new traffic. Make this plan part of your Google Ads management routine.

If ads keep running while your site is down, pausing the campaign makes sense. Then you reopen it once the problem is fixed. This stops the waste right away.

How do you check server logs for 503 responses?

If you manage your own VPS, logs are the most reliable evidence. For example, the commands below assume a common access log format. The log file path depends on your distribution and web server, so use the path from your own configuration.

# Count requests that returned 503 (field 9 is the status code in the combined log format)
awk '$9 == 503' /var/log/nginx/access.log | wc -l

# List the URLs that returned 503 most often
awk '$9 == 503 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Show the last lines of the error log
tail -n 100 /var/log/nginx/error.log

The first command tells you how widespread the error is. Meanwhile, the second shows which URLs it hits. Then you see at once whether the whole site is affected or only one page.

If reading raw logs feels hard, use a log analyzer. Our log file analyzer loads an access log in your browser and summarizes it. On shared hosting you may have no log access. Instead, use the error log section of your panel or ask support.

How do you check services, memory, and disk on a VPS during a 503 Service Unavailable error?

If you have shell access to your VPS, check three things: are the services running, is memory enough, and is the disk full? Together, those three checks explain most 503 cases. Run the commands only on a server you are allowed to administer.

# Show the status of the web server
systemctl status nginx

# Show system load (averages for the last 1, 5, and 15 minutes)
uptime

# Show memory usage in megabytes
free -m

# Show disk usage
df -h

The PHP-FPM service name changes with the distribution and version. So first find its name in the output of systemctl list-units. If the service is inactive, read the log to learn why it stopped, and then restart it. However, restarting without knowing the reason only postpones the problem.

Also, when memory runs out, the operating system may kill processes. The service then stops by itself, and a 503 begins. When the disk fills up, logs and session files cannot be written, so the application locks up. Therefore a monitoring tool makes these checks routine.

If you do not know the service settings, do not experiment. In practice, a wrong configuration can take the whole site offline. When in doubt, ask your server administrator or your provider.

What is the Retry-After header and how do you use it with a 503 response?

Retry-After is an HTTP response header that tells a client how long to wait before it tries again. You can give the value as a number of seconds or as a date and time. MDN recommends that a 503 response carry this header with the estimated recovery time, if possible.

For example, if you know maintenance will take one hour, you set the header to 3600. Google's help page also recommends a 503 together with a retry-after header, using a best-effort date or duration, for a short closure. You can read the details on the MDN Retry-After page.

The header is an estimate, not a promise. So choose a realistic value. A value that is too short makes bots come back for nothing. By contrast, a value that is too long may delay the recrawl of your site. If you do not know the time, use your best guess and update it when maintenance runs long.

Why is a 503 the right status during maintenance, and not a 404 or a 200?

Because the status code tells search engines and browsers what will happen to the page. A 503 says "unavailable now, come back later". By contrast, a 404 says "this page does not exist". Finally, a 200 says "everything is fine, and this is the real content". So if you give a maintenance page the wrong code, a search engine draws the wrong conclusion.

A fake 200 is especially risky. For example, when the maintenance message returns a 200, Google may treat it as real content. We describe the link to soft 404s in our guide to soft 404 errors.

How does Google treat a 503 Service Unavailable error?

According to Google's documentation, 5xx and 429 server errors make its crawlers slow down for a while. The drop in crawl rate is proportional to the number of URLs that return a server error. In other words, the wider the error, the further Googlebot steps back.

However, the same page contains an important warning. Google's indexing pipeline removes URLs that persistently return a server error from the index. So a long 503 stops being a temporary error. You can read the details on Google's page about HTTP status codes and network errors.

On duration, however, Google's page about pausing a business online is clear. Disabling the whole site should last only a very short time, a few days at most. Closing a site completely for even a few weeks can hurt indexing. For a short closure, it recommends a 503 with retry-after.

The robots.txt file is a separate case. According to Google's robots.txt documentation, when the file returns a 5xx error, Google stops crawling the site for the first 12 hours. For the next 30 days it uses the last good version. For that reason, consider keeping the robots.txt URL out of your maintenance rule. Also take a look at our article on why Googlebot crawls less.

What should you check in Search Console after a 503 Service Unavailable error?

Once the error is gone, check how Google sees the site. The Crawl Stats report in Search Console shows the problems Googlebot had with your server. There you can see when server errors rose and how the crawl volume changed.

1. In the Crawl Stats report, find the rise in server errors that matches your outage time.
2. In the page indexing report, look for new "Server error (5xx)" entries.
3. Test an important URL live with the URL Inspection tool.
4. Confirm that the site returns a 200 again after the outage.
5. Watch over the next days whether crawl volume returns to its old level.

Do not be surprised if crawling does not recover at once. Google's documentation says server errors slow crawling, so recovery can take some time. For a full walkthrough, see our Search Console guide. If pages fall out of the index, our article on finding unindexed pages helps.

How do you set up maintenance mode the right way?

A proper maintenance page does three things together: it returns a 503, it shows a short and clear message, and it adds a Retry-After header when possible. The Nginx example below does all three. The domain and directory paths are examples, so adapt them to your setup.

server {
    listen 80;
    server_name example.com;

    error_page 503 /maintenance.html;

    location = /maintenance.html {
        root /var/www/maintenance;
        internal;
        add_header Retry-After 3600 always;
    }

    location / {
        return 503;
    }
}

If you use Apache, you can build the same logic in the .htaccess file. Remember to remove these lines when maintenance ends.

ErrorDocument 503 /maintenance.html
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ - [R=503,L]

If you work at the application layer, you do the same two things in PHP: you set the status code to 503, and then you add the Retry-After header. When maintenance ends, restore the old configuration and confirm with a tool that the home page returns a 200.

What is the difference between 503 and 500, 502, 504, and 429?

These codes look alike, but they mean different things, and their fixes differ too. If you research the wrong code, you waste time in the wrong place. The table below sums up the difference.

MDN notes that a 429 suits rate limiting better than a 503. Therefore, if you limit requests on purpose, a 429 is the more accurate answer. If the fault sits at the gateway, study the 502 and 504 cases separately.

How do a slow site and your hosting choice affect 503 risk?

A slow site holds more work at the same time. Each request takes longer, so the concurrent process limit fills up sooner. In other words, slowness can be a quiet warning of a future 503. Fixing the slowness first lowers the chance that you hit a resource limit.

We collected the causes in our guide to server-side slowness. For the link between speed and search results, read how site speed affects SEO. For the impact on sales, see e-commerce page speed.

When you choose a hosting plan, do not look at price alone. The concurrent process limit, memory, CPU, and traffic policy set your 503 risk. We explain the criteria in our guide on how to choose web hosting. If you plan a campaign, it is a good habit to warn your provider in advance.

Which caching and monitoring settings help prevent a 503 Service Unavailable error?

Prevention means cutting the resource use at the root of the error. The most effective method is to stop pages from being rebuilt on every visit. Caching does that. Monitoring then warns you the moment an error starts.

• Set up page caching, which lowers server load during ad and email traffic.
• Turn on PHP code caching; see our OPcache guide for details.
• For object caching, read our comparison of Redis and Memcached.
• For an HTTP cache in front of your app, our Varnish guide helps.
• Set up an uptime monitor that checks from outside, and send its alerts to your phone.
• Before a campaign, compare your resource limit with your traffic forecast.

These steps shrink the chance of a repeat, but they do not remove it. Sometimes you truly need a bigger plan. Decide that with data, because upgrading on instinct wastes both money and time.

When should you leave a 503 Service Unavailable error to your hosting provider?

The honest answer is simple: if the server setting is not yours to change, do not touch it. On shared hosting, restarting services, changing resource limits, or reading server logs is mostly the provider's job. Forcing something you cannot see in the panel may create a new problem.

Open a support ticket in these cases:

• Resource usage looks low in the panel, but the 503 continues.
• The error affects more than one site at the same time.
• You have no access to server services and cannot read logs.
• You suspect an attack, and your power to block traffic is limited.
• The error lasts longer than a few hours, and SEO risk grows.

In the ticket, write the time window, the affected URLs, and the changes you made. That way the provider reaches a result faster. We are a digital marketing and web team, not a hosting company, so we do not run your server for you. To protect your search visibility after an outage and to run technical SEO checks, see our SEO consulting page.