REST API heart beat standard

Question

For a SaaS product which provide its services via REST API, is it a standard requirement to have a heartbeat API?

I have a debate on this subject at work, in my point of view, the heartbeat API is redundant - in case of outages we have a status page which is exactly for those kind of issues, status page + proper communication,

And for the regular usage of our API -> the API should be consumed as is, and it should have a failover with a proper handling - depends on the consumer and the response code (writing to log, retry, etc...)

Also, I have never encountered an API product which provides a heartbeat endpoint, and while looking online I encountered Opsginie heartbeat proxy capability and other few heartbeats which I don't consider them as standard APIs,

Have you encountered such requirement for an API or encountered an API product which provides a heartbeat endpoint ? That will be really useful for me.

Answer 1

It's a good question. My suggestion is to focus on the consumers of your API and their expectations - ie how mission critical is the API?. If your system was experiencing a severe issue, would your consumer:

1. probably be annoyed and look for notifications / status information (ie wait)?
2. panic and start raising priority one support calls?

If your consumers consider your API to be mission critical, they may well be looking for an automated way of detecting an issue even if they aren't currently using the API for it's main purpose. A lot of mission-critical systems are hooked into monitoring systems of the client and so a heartbeat might be considered highly important for some users/clients/consumers.

If not typically mission critical, then your consumers will probably never use it so no need to implement.

I hope that helps.