503 is the only error you are supposed to send on purpose
Among the five hundreds, this one is odd. A 500 is a bug. A 502 is a broken conversation. A 504 is a stopwatch. A 503 might be any of those, or it might be you, deliberately, telling the world to come back in ten minutes.
That ambiguity is not a flaw in the specification. It is the reason the specification gives you a header to resolve it, and the reason almost nobody sends that header.
Retry-After is the whole difference
A 503 with a Retry-After header is a promise: the service is coming back, here is roughly when. A 503 without one is indistinguishable from a crash. Search engines treat the two differently, and so should your monitoring.
curl -sSI https://example.com/ | grep -iE 'HTTP/|retry-after'If your maintenance page does not answer with that header, add it. WordPress's own maintenance file, the one core drops during an update, does send it. Most maintenance-mode plugins do not, and most custom holding pages built by hand return 200 with the words "we will be back shortly" in the body, which is the worst of the available options: search engines will happily index that sentence as the content of your client's homepage.
The three sources, and how to tell them apart in one look
| Source | Tell | What to do |
|---|---|---|
| Deliberate maintenance | Retry-After present, same response on every path, including static files | Nothing. Confirm the window and move on. |
| Rate limiting | Only some clients or some paths, often with a vendor header naming the limiter | Find out whose limit. It may be your own monitoring, which is a real and embarrassing cause. |
| Overload or crash | No Retry-After, static files still answer 200, errors are intermittent | Treat it like a 502 with a nicer error page: the application pool is the suspect. |
The second row is worth dwelling on if you watch a lot of sites. A checker hitting forty client sites hosted on the same shared IP range, every minute, from the same address, looks exactly like something a rate limiter was built to stop. Your monitoring reports an outage, the site is fine for everyone else, and the only evidence is that the outages started the day you added the fortieth site.
The deploy that deindexes
Here is the sequence that costs real money, and it does not involve anything crashing.
A site goes into maintenance mode for a plugin update. The holding page returns 200. The update takes forty minutes because someone went to lunch. Google recrawls a few pages in that window and stores a homepage whose entire content is a wrench icon and a sentence. The site comes back, everything looks normal, and rankings drift for three weeks while nobody connects the two events.
The same window with a proper 503 costs nothing at all. Google's documented behaviour is to retry, and short 503 windows are explicitly the case the code exists for. The difference between the expensive version and the free version is one line in a header.
There is a limit to the trick, and it is worth knowing: a 503 that lasts for days stops being read as temporary. If a client site is going to be down for a week, a 503 is no longer the honest answer.
What monitoring should do with a 503
Most tools have one setting for this, and it is a checkbox: treat 503 as down, yes or no. Both answers are wrong.
If you treat it as down, every planned deploy pages you. Teams respond by disabling the monitor before deploys, then forgetting to re-enable it, which is how sites go unwatched for months. If you treat it as up, a genuinely overloaded server reads as healthy.
The distinction the tool should make is the one the protocol already gives it. A 503 carrying Retry-After, on every path, is a maintenance window: record it, do not alert, and start a clock so that a window running longer than the promise does alert. A 503 without the header, or on some paths only, is an incident.
That is a small amount of logic, and almost no checker does it, because almost no checker reads anything except the number. The same blind spot shows up in the way intermittent 502s go unreported, and in the broader case of a page that answers slowly rather than not at all.
If you landed here from a 504 rather than a 503, the two are not the same event wearing different numbers. A 503 is an intention, a 504 is a duration, and the difference fits in a paragraph.
If you want to check what a given address is really sending right now, headers included, the free tool here will show you.
