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

Q: How do I fix "Service Temporarily Unavailable" on WordPress?

First delete the hidden .maintenance file in your site's root folder if an update was interrupted. If that isn't it, rename the plugins folder over SFTP to test for a plugin conflict, then the active theme. If the error persists, ask your host whether your account is hitting resource limits.

A 503 Service Unavailable error means the server received your request but can't handle it right now. Usually it is overloaded or in maintenance, as MDN's reference for the status code describes. If you are a visitor, wait a few minutes, reload, and contact the site if it persists. If you run the site, the fix is on the server: check resources, logs, maintenance mode, plugins and any firewall or CDN in front of your origin.

This guide covers both sides. It starts with a quick read on who can fix what, then walks through a site owner's diagnosis in order, with a separate section for WordPress.

inSave Hosting

Reduce recurring 503 errors

InSave Hosting offers performance-focused hosting, WordPress tools, and managed security features for site owners troubleshooting server overload.

Explore hosting options

TL;DR

A 503 is a temporary, server-side status: the server is down for maintenance or overloaded, and it is not a problem with your browser or your device.
Visitors can only retry later or contact the site. Owners need to check server load, logs, maintenance mode, plugins, and firewall or CDN rules.
On WordPress, a stuck maintenance file, a faulty plugin or theme, or exhausted PHP resources cause most cases.
Find out whether the 503 comes from your origin server or from a proxy like a CDN before changing anything.
Recurring 503s usually mean the plan is too small or the site isn't monitored. Both are fixable.

What a 503 error actually tells you
If you are a visitor: what you can do
If you own the site: a diagnosis in the right order
Fixing "Service Temporarily Unavailable" in WordPress
Our perspective: why 503s keep coming back
Preventing recurring 503 errors
When it is time to change your hosting
FAQ
Sources

What a 503 error actually tells you

HTTP status codes starting with 5 mean the server failed to fulfill a valid request. A 503 is the specific one that says "not ready". The server is reachable, it understood you, and it chose, or was forced, to decline. MDN describes it as the server not being ready to handle the request, commonly because of maintenance or overload.

Two details matter in practice:

It is meant to be temporary. Per MDN, a well-behaved 503 response should carry a Retry-After header with the estimated time until service recovers, if the server can estimate it. Most site error pages don't show it, but tools like curl -I will.
It is often deliberate. Some applications return 503 on purpose when memory, CPU or connection-pool limits are hit. Dropping requests creates backpressure and protects the server from a worse failure.

You will see the same code under many wordings: "503 Service Unavailable", "HTTP Error 503", "Service Temporarily Unavailable", or "The server is temporarily unable to service your request". They are the same status with different page templates.

503 vs. 500, 502 and 504

These neighbors get confused constantly, and the difference tells you where to look.

Code	Plain meaning	Where to look first
500	The application crashed or hit an unexpected error	Application error logs, recent code changes
502	A gateway or proxy got an invalid reply from the server behind it	Upstream service, PHP handler, proxy settings
503	The server can't take requests right now (overload or maintenance)	Resource usage, maintenance mode, limits
504	A gateway timed out waiting for the server behind it	Slow scripts, slow database, timeouts

If your symptoms look more like a bad gateway, our guide on how to fix a 502 Bad Gateway covers that branch.

If you are a visitor: what you can do

You can't repair someone else's server, but a few quick checks save time:

Wait two to five minutes and reload. Maintenance windows and traffic spikes often pass quickly. MDN's own advice to visitors is to try again later and contact support if the problem persists.
Check whether it is just you. Try another browser, a private window, or your phone on mobile data. If the site loads there, clear your cache or flush your DNS.
Check the site's status page or social accounts. Planned maintenance is usually announced there.
Don't hammer refresh. Repeated reloads add load to a server that is already struggling.
Contact the site owner. Give them the time, the URL and the exact error text. It speeds up their diagnosis.

The same logic applies to apps and services you use rather than own, such as email, streaming or media servers. A 503 from a hosted service is almost always on the provider's side, so the status page is your best first stop. If the 503 appears only for your own self-hosted instance, you are in the next section.

If you own the site: a diagnosis in the right order

Because a 503 is a server-side issue, you can ignore front-end code like HTML, CSS and browser JavaScript while troubleshooting, as developers commonly note. Work through the chain from the outside in.

Step 1: Find out who is sending the 503

If your site sits behind a CDN or proxy, the 503 may come from that layer rather than from your server. Cloudflare's troubleshooting docs say to determine whether the error originates from your origin or from Cloudflare and to inspect the response body. The body or the headers usually name the sender.

The same applies to other CDNs. Amazon CloudFront, for example, can return a 503 when it can't connect to a custom origin over mutual TLS, such as when handshakes repeatedly fail or the origin is unreachable because of DNS or connectivity problems. In that case, restarting your web server will change nothing.

A quick test: request your site directly from the origin IP or bypass the proxy temporarily, then compare. If the origin answers normally, the problem is between the proxy and the origin.

Compare proxy and direct origin 503 tests

Step 2: Read the logs

Server logs often hold the details that narrow the root cause, as MDN notes. Cloudflare's guidance points to the same signals: look for overload, CPU or memory saturation, exhausted connection pools, or application-level maintenance mode.

What to search for:

Resource-limit messages in the error log, such as processes or entry limits reached, or out-of-memory kills.
Spikes in requests around the time the errors started: one IP, one URL, or one bot hammering a page.
Application errors immediately before the first 503: a fatal PHP error after an update, a database connection failure, a crashed worker.

If you want to go deeper into reading access logs to spot server bottlenecks such as CPU, memory and connection exhaustion, this walkthrough on log file analysis for crawler and CDN blind spots shows what the patterns look like at scale.

Step 3: Check for overload

Overload is the most common story. Your plan has fixed CPU, memory, process and connection limits. When traffic, a heavy plugin, a slow query, or bots push past them, the server starts refusing requests. Signs:

Errors come and go, worse at peak hours or after a newsletter or social post.
Your hosting control panel shows resource usage touching its limits.
The site recovers by itself, then fails again.

Short-term fixes: cache more aggressively, block abusive bots, disable the heaviest plugin or scheduled job, and put static assets behind a CDN. Our guide to setting up a CDN for your website explains how offloading images, scripts and stylesheets reduces origin load. Long-term, the fix is either optimizing the application or moving to a plan with more headroom.

Step 4: Look for maintenance mode

Some platforms and deployment tools put the site into a maintenance state and return 503 on purpose, then fail to lift it when an update is interrupted. Check your framework's or CMS's maintenance flag, your deploy scripts, and any maintenance setting at the server level. If you want direct control over automatic maintenance updates, you can disable them in server configuration. Do that only if you are prepared to apply updates yourself on a schedule.

Step 5: Check firewall and security rules

A misconfigured firewall can mistake legitimate traffic from a content delivery network for an attack and reject it, which can surface as a 503. If the errors started right after you enabled a security plugin, a WAF rule, or a CDN, review those first and allow the CDN's address ranges. For the trade-offs between the two layers, see our comparison of WAF vs. CDN.

Step 6: Restart services, carefully

Restarting the web server can sometimes clear a 503 caused by congestion in the server chain. Treat it as a way to buy time, not a fix. If the 503 returns within hours, a restart only confirmed that something is exhausting resources, and you still need the logs from Step 2. If you are on shared hosting you can't restart services yourself, so open a ticket with your host.

Step 7: Reproduce it outside production

If the cause is in your own code, copying the site to a development machine and debugging there can show why the server can't answer correctly. Use a staging copy so you can test fixes without further downtime for real visitors.

Fixing "Service Temporarily Unavailable" in WordPress

On WordPress, a 503 almost always traces to one of four things: a stuck maintenance file, a plugin, a theme, or hitting resource limits. Take a full backup of files and database first, so every step below is reversible.

The "Briefly unavailable for scheduled maintenance" message

When WordPress updates a plugin, theme or core, it creates a hidden file named .maintenance in the site's root folder and removes it when the update finishes. If the update is interrupted by a timeout, a closed browser tab or a crash, the file stays and visitors keep seeing the maintenance message. Connect over SFTP or your host's file manager, enable hidden files, delete .maintenance from the root folder, and reload. Then rerun the interrupted update.

Stuck maintenance file keeps WordPress unavailable

Plugins and themes

If the admin area is unreachable, you can reset plugins and the theme by file. Via SFTP, FTP or a file manager, rename the plugins folder and the active theme's directory to rule them out:

Rename wp-content/plugins to plugins-off. If the site returns, a plugin is the cause.
Rename it back, then rename individual plugin folders one at a time to find the culprit.
If plugins aren't the cause, rename the active theme's folder. WordPress falls back to a default theme if one is installed.
Replace or update the culprit, or remove it and find an alternative.

Prime suspects are plugins that make many external calls, run heavy scheduled tasks, or were just updated.

Resource limits and slow code

If plugins aren't the cause, look at what your plan allows. Backup plugins, image optimizers, page builders, and heavy admin screens can consume memory and processes in bursts. Turn on debug logging in wp-config.php to catch fatal errors, reduce the frequency of the WordPress Heartbeat API, enable page caching, and check whether bots are hitting wp-login.php or xmlrpc.php. If the host's limits are the bottleneck, ask for the exact limits reached, which should appear in the host's resource report.

Temporarily bypass the CDN

If you use a CDN or security proxy, pause it for a few minutes and test. If the site loads, the problem is in the proxy configuration or the connection to your origin. Our CDN integration step-by-step guide shows how a correct origin setup should look.

Our perspective: why 503s keep coming back

We run hosting infrastructure, and the pattern we see is consistent: a one-off 503 is an event, but a repeating 503 is a signal. The site is outgrowing its plan, or something in it is wasteful, or nobody is watching it.

A few things we'd tell any site owner:

Fix the cause, not the symptom. Restarting a service and moving on guarantees a repeat. Read the logs and name the cause, even if the answer is "we need more resources".
Match the plan to the workload. Shared hosting is right for brochure sites, blogs and small stores. A growing WooCommerce shop or a traffic-heavy site is better served by WordPress-optimized hosting, a VPS or a dedicated server, where resources aren't shared with neighbors.
Offload what doesn't need your origin. Caching and a CDN take repetitive traffic away from PHP and the database. This is the cheapest capacity you can add. Our stack uses LiteSpeed with LSCache for exactly this reason.
Know before your visitors do. Monitoring that alerts you within minutes turns a lost afternoon into a short blip. See our website uptime monitoring guide.
Have engineers who read logs. Our customers' sites are managed by SRE and DevOps engineers in the EU and US, and we want a 503 report to start with a log line, not a script of generic advice.

— Ihor

Preventing recurring 503 errors

Once the site is back, spend an hour on prevention:

Set up uptime monitoring with alerts to email or chat, and watch response time as well as up or down. Our 360 Monitoring page describes what we offer.
Cache everything you can: full-page caching for anonymous visitors, object caching for the database.
Keep staging and production separate. Test plugin and theme updates on a copy before pushing them live.
Update on your schedule. Run updates off-peak, one at a time, with a backup taken first.
Review the causes of past downtime. A written map from symptom to fix, like our seven-step playbook on website downtime causes, makes the next incident shorter.
Plan for traffic events. Before a launch, sale or campaign, raise your limits or move up a plan in advance.

When it is time to change your hosting

A better plan is the right fix when your logs show you hitting limits while the site is already well cached and lean. Other signs: the host can't tell you what limit was reached, 503s cluster at predictable traffic peaks, or you have no staging or backups to recover from.

Here is how our plans map to common situations:

Shared hosting for small business sites, portfolios and blogs.
WordPress hosting for sites that need staging tools, managed security and WordPress-tuned caching.
VPS hosting when you need dedicated resources and root-level control.
Dedicated servers for high-traffic or resource-hungry workloads.

Every plan includes free migration, so moving an existing site doesn't mean rebuilding it, and a 30-day money-back guarantee lets you test the fit. Daily backups and honest renewal pricing round out the basics. If you aren't sure which plan fits, send us the symptoms and your resource numbers and we will help you choose.

FAQ

Is a 503 error my fault or the website's?

Almost always the website's. A 503 is a server-side status, so your browser or device is rarely the cause. Trying another browser or network quickly confirms it, and if the site loads elsewhere, clear your cache and DNS.

How long does a 503 error last?

It depends on the cause. Brief overloads and short maintenance windows can clear within minutes, while a faulty plugin, an exhausted hosting plan or a stuck maintenance state stays until someone fixes it. A server that provides a Retry-After header is telling clients when to try again.

Can a 503 error hurt my search rankings?

A short outage is unlikely to matter, since 503 tells crawlers the condition is temporary. Repeated or long-lasting 503s are a different story, because search engines may crawl the site less and visitors lose trust. Fix recurring errors quickly and monitor uptime so you notice early.

How do I fix "Service Temporarily Unavailable" on WordPress?

First delete the hidden .maintenance file in your site's root folder if an update was interrupted. If that isn't it, rename the plugins folder over SFTP to test for a plugin conflict, then the active theme. If the error persists, ask your host whether your account is hitting resource limits.

Does restarting the server fix a 503?

Sometimes. Restarting can clear congestion in the server chain, but if the underlying cause is overload, a bad plugin or a misconfigured firewall, the error comes back. Use it to restore service, then read the logs for the real cause.