[kevincox]

> We don't do email notifications!

Weird choice. SSL certificates are generally not urgent enough that I need to act right away, so any IM notification will be forgotten before I can act on it. Furthermore email is the most widely supported communication system as opposed to proprietary chat systems.

[jabart]

Email is expensive, require extensive monitoring, bounce checking, extra storage, opt-in verification. Webhooks are cheap and quick.

1 email is $0.0001 on AWS SES 1 webhook is ~$0.00000083 assuming 512mb for 100ms.

[adrukh]

You are totally correct! But another way in which email is 'expensive' is troubleshooting deliverability issues, handling bounces, unsubscribes, landing in the 'promotions' tab of your gmail inbox, etc.

Webhooks are... easier to consume.

[adrukh]

This is intentional (although may change in the future), for one main reason - I believe that email is personal, and webhooks are a much better way to notify _teams_. Strongly believe that SSL expiration handling is a team effort!

Thanks for this feedback!

[AnIdiotOnTheNet]

You speak as though mail groups were not invented several decades ago and don't see widespread use in pretty much every organization that uses email.

[adrukh]

Sorry, wasn't clear - I want to get the minimal input from my users, and right now all I have is the google email.

Totally agree that to capture the audience that relies on email, asking for a mailing list for notifications is much better than notifying the personal email address I get via SSO.

Some current stats on this: 12.5% of the registered users have added a webhook of some sort to their account. This is the primary engagement metric for me, it's very low, but I want to find a way to drive it up before I give in to email :)

[kevincox]

Other than mailing list and shared inboxes it also seems that every oncall system and enterprise chat tool has support for receiving email. Email is just the standard protocol, people can consume it however they want.

[qwertox]

I agree with this.

And it's not only teams who would use this service, since it has a generous free tier.

If I hadn't built my own system, I'd definitely use this one, and receiving an email would be nice as a reminder which could hang around in the inbox until I have time to deal with it (if I'd had the need to, since it's all automated). I don't use Slack, nor Discord, but XMPP, and if I'd set up a Webhook handler, it would end up sending me an email and XMPP notifications.

I have a small custom SMTP server which serves as a "webhook" handler for me to get USGS Earthquake Notification Service (ENS) notifications as well as backup success notifications from my VPS provider, since they don't provide Webhooks. So I'm basically doing it the other way around.

Maybe offering it as an experimental "no guarantees" service would be useful for many of us and give the service provider a chance to learn how to send emails from their own servers in such a way that they actually reach their destination without getting flagged as spam.

I also found no information on what happens if the Webhook endpoint is not reachable.

I like the idea of this SSL expiry checking service and the site looks nice.

[adrukh]

Thank you, this is quite insightful!

> I also found no information on what happens if the Webhook endpoint is not reachable.

When setting a webhook, the app checks it for validity (you get a nice 'hooray, it works!' message posted through the webhook). So if the webhook URL is bad, the app won't accept it. But once accepted, there is no retry policy if a specific notification fails. The failure will be logged internally for troubleshooting, but not presented to the user in any way right now.