The app was brought back up but put under maintenance: it answers every request with maintenance and the HTTP status 503. Check what exit status curl ends with on such an answer.
Ask the app under maintenance
In ~/health-lab, ask the app with curl twice — without the -f option and with it — and look at curl's exit status after each request.
First, predict
The app answers with status 503. What exit status will the first command, without -f, print for curl?
Now start the exercise, run the command and compare your prediction with the output.
curl's status describes the exchange: it connected, sent the request and got an answer — a success, whatever status the answer carries. The 503 status is part of the answer, and without options curl does not judge it.
The -f option (--fail) turns an answer with status 400 or above into a failure: curl prints no body and ends with status 22.
Sometimes a server accepts the connection and stays silent. curl waits for an answer, and the check hangs along with it. The --max-time 2 option limits the whole request to two seconds: when the timeout expires, curl ends with status 28. timeout limits any other command the same way: timeout 5 command stops it after five seconds with status 124.
A healthcheck must treat as a failure both a 503 answer and a server that accepted the connection and stays silent. Which request fits it?
-
timeoutcuts off a silent server with status 124, but without-fa 503 answer is a success for curl, status 0. -
-fcatches the 503, but curl will wait for a silent server: there is no time limit here. -
This curl ends with status 0 on a 503 answer and waits for a silent server with no end.
-f turns an answer with status 400 or above into a failure (status 22), and --max-time 2 cuts off a silent server after two seconds (status 28). Together they give a nonzero status in both cases.