Web Technician Online

503 Service Unavailable: separate maintenance from overload

Check whether maintenance was deliberately enabled and whether there is a Retry-After response header.

Request → Server response → Next check
Use the response code, the failing URL and the time of the error to choose a specific next check.

What does this mean?

The service is temporarily unable to handle the request. Planned maintenance, exhausted resources or an unavailable dependency can all be responsible. A visitor sees the same code in several different situations, so increasing capacity before checking the evidence can waste time and money.

What should I check first?

Check whether maintenance was deliberately enabled and whether there is a Retry-After response header. Record when the failure began and whether it affects all users or one operation. Consult the provider status page and recent deployment notes before changing the site.

How can I diagnose the cause?

Inspect resource graphs and application logs for the same interval: worker limits, database connections, memory and queued work are useful leads. Compare request volume with a normal day. A plugin making repeated external requests can cause resource pressure even without unusually high visitor traffic.

How do I fix it safely?

For intentional maintenance, complete the scheduled work and remove maintenance mode through the documented mechanism. For overload, address the specific bottleneck, stop an identified runaway task or restore a known working release. Cache public content where suitable, but do not cache private account pages or successful payment responses indiscriminately.

Verify the fix and know when to contact your provider

Take a configuration copy before adjusting worker or database limits. Watch resource use after the fix and test important paths. If the hosting platform enforces a limit you cannot control, send the host the relevant graph, error lines and times. Ask which resource is exhausted instead of requesting an unexplained restart.

Work through these checks in order

  1. Check the hosting and application maintenance controls before treating the error as overload. Record whether an administrator deliberately enabled maintenance during an update.
  2. Open resource usage in the hosting panel and capture the interval covering the failure. Look for a named limit rather than assuming more bandwidth is the answer to memory or worker exhaustion.
  3. After a targeted fix, monitor a fresh interval and perform one safe form submission. A homepage that loads from cache does not prove that the application has recovered.

Which tool can help?

Uptime & downtime calculator · Website bandwidth calculator

DNS tools show one resolver’s public answers. Record explainers do not authenticate a message, and calculators do not monitor a server. Use the evidence alongside your provider’s logs.

Reference

Official technical documentation