Server
HTTP 503
Also called Service Unavailable.
HTTP 503 is the status code for 'Service Unavailable': the server cannot handle the request right now because of overload or maintenance. It signals a temporary condition and may carry a Retry-After header.
How it is measured
Count 503 responses by path and by source: your app, your proxy, or a CDN in front. Note whether a Retry-After header is present and what it says. A planned maintenance 503 should have one.
Compare 503 volume with concurrency and queue depth. If 503 appears when workers are all busy and the queue is full, you have found your capacity limit.
Worked example
A WooCommerce site on 8 PHP-FPM workers runs a flash sale. At 12:00 the request rate triples and the listen queue fills, so Nginx begins returning 503 on about 35 percent of product-page requests for four minutes.
The fix was a full-page cache for anonymous visitors, which cut PHP requests by 80 percent. A static maintenance page with a 503 and Retry-After: 600 was used for the later database migration so search engines did not index it.
How it differs
HTTP 503 says the service cannot take the request now. HTTP 502 says a gateway received a bad reply from upstream. A 503 excludes a broken response, it is a refusal or a closed door. A 502 excludes a deliberate refusal. Search engines treat a short 503 as 'come back later', which is why it suits maintenance.
Common errors
Serving a maintenance page with 200, so Google indexes it. Leaving out Retry-After. Treating every 503 as a crash when the app is shedding load on purpose. Counting maintenance windows as outages without noting the plan. Using 500 for overload so clients cannot tell the difference.
In practice
Make your maintenance page return 503 with a Retry-After, and test it from outside. Review where load shedding returns 503 in your stack and put those counts on a dashboard, separate from 5xx crashes.