For our app it's super important as if our server goes down, users can download the app but get stuck at the sign in flow. There's subscription services out there that do more in-depth monitoring but this is all we needed.

I listed an alternative solution below for those wanting to build or customize their own solution, ours just gets the job done, is quick to set up, and you can avoid the monthly twilio/sms fees.

Other alternative we received as feedback for those interested: "If any one wants an AWS Native way and assuming it has ALB you can target elb metric 503 via Cloudwatch Alarm and create an output to an SNS topic that goes to Slack, or use AWS chatbot/q, or set number as destination for sms via sns"

With that being said, I find these kinds notifications to provide more false positives than correctly detecting downtime. That ends up costing more time checking/double checking.

On the other hand, if you are running a service with no users and you have downtime... did you really have downtime?

If you run a service and you have downtime and no one reports it, did you have downtime?

I don't even check for my services. If something goes down, I'll find out via email from one or more of my customers. It happens very rarely.

This tool wouldn’t be useful for most (if not) all enterprise services I’ve worked for. For enterprise, you want fully featured synthetics services such as Thousand Eyes, plus an internal monitoring and alerting system.

Also you typically don’t want to expose your health endpoint to the outside world. It’s a security risk.

https://oss.oetiker.ch/smokeping/

Also Tianji[1], self-hosted in the same space.

Of course, these require setup and have to be hosted somewhere. Either another server or deployed to Heroku (Sealos, Render, etc), since they obviously cannot be deployed on the server you wish to monitor!

[1]: https://tianji.msgbyte.com/