1

I have a web application, for which I have an isalive page that gets hit on a regular basis (monitoring) to make sure my application is working (or is alive as the name suggests).

In general, this isalive functionality/page is very light in terms of processing. It checks things that the application depends on like SQL connectivity, Fileshare connectivity etc (on top of obviously verifying that the app itself on the web server can server this current isalive request).

Currently we use HTTP status code 200 for success and HTTP status code 500 for failure (we set the HTTP status code on response). But some how I feel, this is not accurate (in my opinion), since HTTP status code 500 is internal server error, and may not be accurately representing failure condition, since failure could be thrown, not only due to web level failure, but could also be due to dependency failure like SQL, FS connectivity checks.

Since this seems like a fairly standard use case for many, what is the industry standard for this? Am I doing it right? Suggestions or how you have been handling this would be much appreciated.

Mahesh Velaga
  • 21,633
  • 5
  • 37
  • 59
  • HTTP protocol only defines status codes for HTTP specific things. Since you are in fact trying to serve application specific purposes, try to avoid using any HTTP ones to avoid conflicts and misunderstanding. – Lex Li Oct 30 '15 at 19:38
  • 1
    Possible duplicate of [Which HTTP status code should I use for a health-check failure?](https://stackoverflow.com/questions/25389261/which-http-status-code-should-i-use-for-a-health-check-failure) – geisterfurz007 Feb 28 '18 at 13:56
  • Duplicate of https://stackoverflow.com/questions/25389261/which-http-status-code-should-i-use-for-a-health-check-failure, which lists good reasons for using 503 instead of 500 to indicate failure. – geira Feb 28 '18 at 13:54

1 Answers1

1

200 and 500 are perfectly accurate for your use case.

If your isalive page is used by an automated monitoring service such as pingdom or wdt.io (as opposed to a human), you could change it to return a 204 (no content) because that would be more efficient.

From the client's perspective, the web server, database, and filesystem are all part of the server. So if one of them fails, a 500 response is correct. If you want to distinguish web server errors from other, upstream services, you could return 502 if one of these upstream services failed. Personally, I wouldn't bother and try to keep the implementation for isalive as simple as possible.

Christian Pekeler
  • 980
  • 7
  • 10