Let's Encrypt expiration emails have ended.
Let's Encrypt ended expiration emails on June 4, 2025. Learn how renewal signals, endpoint checks, and certificate observations complement each other.
The expiration email is gone. The need for visibility remains.
Let's Encrypt ended its expiration notification emails on this date. Your team now needs its own way to keep track of certificate validity and the systems that use those certificates.
Automation does the work.
Monitoring adds perspective.
Certbot can automate certificate renewal. But a renewal job, a certificate file, and a working TLS endpoint are different things. A job can fail; a service can miss a reload; one load balancer can keep serving an older certificate.
A useful monitoring approach asks separate questions: did automation run, what certificate metadata was observed, and what does the endpoint actually present? One signal rarely answers all three.
You do not need a complicated monitoring platform to start. You need a clear owner for each question and a way to investigate when the answers disagree.
Choose the signal for the question.
These approaches work together. Their limitations matter as much as their strengths.
Local renewal signals
Review Certbot runs, scheduler results, and local logs to understand your renewal automation.
- Useful for
- Knowing whether a renewal attempt ran and what it reported.
- Still needs checking
- Whether each intended service loaded and serves the expected certificate.
Active endpoint checks
Connect to the intended TLS endpoint and inspect the certificate it presents.
- Useful for
- Checking hostname, validity, and certificate state for the tested connection.
- Still needs checking
- Other endpoints, regions, or backends outside that check's vantage point.
CT observations
Read public Certificate Transparency logs for matching certificates or precertificates.
- Useful for
- Visibility into public certificate and precertificate records.
- Still needs checking
- Actual deployment, endpoint health, and whether coverage is complete.
CT visibility is subject to log coverage and collection delay. A precertificate may be logged before final issuance. Understand observed vs. deployed certificates.
A clearer record of your certificate observations.
BamGuard connects certificate visibility with the Certbot DNS-01 workflow. Monitoring Roots registered through the Hook give your team a place to review matching observations and their validity dates.
See the Certificate Monitoring demoCertificate observations
Review matching certificate metadata and when BamGuard first detected it. First detection is not the certificate's issuance time.
Validity in context
See the validity dates of observed certificates. Those dates do not establish which certificate an endpoint currently serves.
Observation notifications
Keep certificate observations visible to your team alongside the inventory. Keep your renewal and endpoint checks in place.
Give each signal a job.
A small, explicit routine is easier to trust than a single reminder with an unclear meaning.
- 01
Keep renewal automation observable
Check that your scheduler runs Certbot and make failures visible to the team responsible for renewal.
- 02
Review observed certificate validity
Use an inventory to understand what has been detected, and investigate unexpected gaps with your local evidence.
- 03
Verify what your users receive
Check the intended endpoints after deployment. Include the CDN, load balancer, or service that actually terminates TLS.
A couple of useful distinctions.
Does monitoring replace Certbot?
No. Certbot handles ACME certificate requests and renewal automation. Monitoring provides additional evidence to help you understand the resulting certificate state.
Do observed validity dates prove the live certificate is current?
No. An observed certificate may not be deployed. Compare its identity and validity with the certificate served by your actual endpoint.