Re: Appropriate use of HTTP status codes for application health checks

[Mark Nottingham <[e-mail]>]

Hi Matt,

My .02 -

What's most important when choosing a status code is what generic semantics you want to expose to *generic* HTTP software --  client libraries, proxies, load balancers, etc. They'll use them to do things like  retry requests, assign default caching policies, invoke error recovery, etc.

So, there are arguments for a 500 or a 200 here, depending on what you want generic HTTP software to do. I think most people would go for 500 (if only for the reason that Willy mentioned; some load balancers expect it).

If you choose 5xx, *don't* create a new one -- there isn't any point in application-specific status codes (see above). 500 is perfectly good for it; if more nuance or detail is necessary, you can carry that in headers and/or the body.

Cheers,



> On 23 Feb 2017, at 11:54 am, matt <[e-mail]> wrote:
> 
> Hello,
> 
> 
> 
> My colleagues and I are involved in a debate about the proper usage of HTTP return codes for application health pages.
> 
> 
> 
> For instance, you have a /health page that returns JSON listing your application’s dependencies as either “Up” or “Down”
> 
> 
> 
> Some suggest that it is acceptable for your /health page to return an unassigned 5xx or 503 if the /health page returns successfully, but the page results indicate the application is not healthy. Spring Boot has done this. Although I have reservations about 503 since your request for the page was handled successfully.
> 
> 
> 
> Other contend that your /health page should always return a 200 regardless of whether the page results is indicative of application health or not. 
> 
> 
> 
> As a layman I can see the argument for both sides, and it seems both practices have been used in the past. I perused the RFCs but I don’t feel like I found the ‘silver bullet’ answer on this.
> 
> 
> 
> Kindly,
> 
> Matt
> 

--
Mark Nottingham   https://www.mnot.net/