Haven't they always, from day one, insisted that their primary goal was to encourage (force) automation of certificate maintenance, as a mechanism to make tls ubiquitous (mandatory everywhere)?
And?
Automation sometimes breaks, both for internal reasons (OS patching) or external. For the latter, LE at some point in the past changed CDNs, and this caused JWST headers to be sent back differently, which broke different clients, e.g.:
* https://community.letsencrypt.org/t/jws-has-no-anti-replay-n...
* https://github.com/dehydrated-io/dehydrated/issues/684
Being able to get e-mails was an extra level of monitoring that was handy, even if you had automation.
And you set up your own monitoring systems for your own infrastructure, as you have always done.
Or better yet, set up auto-renewal as per vendors recommendation.
Vendors - especially vendors you aren't paying - may provide some reminder services, but assuming those to be your sole method for 'managing' your renewals is a deeply poor operational position.
This is going to get really important as cert longevity gets reduced, eg https://news.ycombinator.com/item?id=43693900
If you're using Prometheus or Prom-friendly systems - https://github.com/ribbybibby/ssl_exporter
The team lead couldn't get over the slogan "devops, automating downtimes since 2010" whenever someone wanted to add a new nonessential automation that does things on prod servers.
I mean he wasn't completely wrong, it was a non essential automation with high risk and very little reward (<1h saved every 2 yrs), which is why we never switched to LE for our main site, only internal tooling was allowed to use it
https://www.digicert.com/blog/tls-certificate-lifetimes-will...
I was merely retelling an anecdote about how LE was always positioned to be exclusively about refreshing certs automatically, though. As I've moved out of (dev-)ops roles around 2016/2017 so I'm really not up to date with operations topics