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.

Embryo

If you are using netcore, there is something already built-in for that (health checks) – Churrigueresque

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.

Ulysses

First of all, I really liked your answer, Second, I encountered some SaaS products with status page where you can subscribe to events like outages and incidents (codeship, bitbucket, etc...) - I think that this might be a good solution for the "...automated way of detecting an issue...". – Embryo

That makes perfect sense. If the subscribe can be hooked into automatic notifications/monitoring on your side then everyone should be satisfied. One thing to note is that the notifications of incidents/outages is slightly different from a heart-beat since the incident/outage notification is typically human initiated on the vendor-side (so might be deferred/subjective). – Ulysses

Hey! You might also recommend to developers that consume your API a way to monitor it in their app. Have a look at Bearer.sh. That's what we do. – Dues