You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 25, 2020. It is now read-only.
This is just a suggestion - in the docs there is a section called Set up custom HTTPS monitoring that advises to create a custom lambda function and cloudwatch metric to monitor an endpoint.
However, Route 53 now has this capability and it works with Cloudwatch as well. You can even include metrics for latency, and then import the metric from cloudwatch to your status page without having to further configure any functions.
The text was updated successfully, but these errors were encountered:
It’s an interesting idea!
I see mainly two arguments to be made for sticking with lambda-watchtower:
Route 53 is much more expensive: measuring latency for a single external HTTPS endpoint would cost USD 4.75/month while lambda-watchtower costs hardly anything
lambda-watchtower is more easily extendable and configurable. It already supports non-HTTP(S) port checks and SMTP, for example.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is just a suggestion - in the docs there is a section called Set up custom HTTPS monitoring that advises to create a custom lambda function and cloudwatch metric to monitor an endpoint.
However, Route 53 now has this capability and it works with Cloudwatch as well. You can even include metrics for latency, and then import the metric from cloudwatch to your status page without having to further configure any functions.
The text was updated successfully, but these errors were encountered: