I’m currently working with a client that doesn’t have a health endpoint or any kind of monitoring on their new API . They say monitoring isn’t needed because it will never go down.
Naturally it went down on day two. They still haven’t added any “unnecessary” monitoring, insisting that it will never go down.
Just have an endpoint in your API (like /health) that doesn’t do anything but return “ok”.
So if your database goes down, your filesystem is full, etc, that endpoint will always return “ok” with HTTP 200. That way you can setup a ping monitoring service that will trigger an alarm if the process itself is down.
You of course need more pinging for the database server etc. But at least you know which service is down instead of “the whole website is down and we don’t know which parts”.
I’m currently working with a client that doesn’t have a health endpoint or any kind of monitoring on their new API . They say monitoring isn’t needed because it will never go down.
Naturally it went down on day two. They still haven’t added any “unnecessary” monitoring, insisting that it will never go down.
If you never know when it goes down to you it never goes down
Think smarter, not harder
Schrödinger’s status
This kind of hubris may be an opportunity for contractual fuckery…
deleted by creator
I never wrote an api that had a health system. Could you help me understand why that matters and how that helps ?
Just have an endpoint in your API (like
/health) that doesn’t do anything but return “ok”.So if your database goes down, your filesystem is full, etc, that endpoint will always return “ok” with HTTP 200. That way you can setup a ping monitoring service that will trigger an alarm if the process itself is down.
You of course need more pinging for the database server etc. But at least you know which service is down instead of “the whole website is down and we don’t know which parts”.
Health checks are the only reason I’ve used 204 no content responses, so there’s that too.
Removed by mod