Guide
Monitor Let's Encrypt renewals
Certificates from Let's Encrypt usually last about 90 days, so a renewal is a routine event rather than a yearly surprise. Certwatch can show the logged certificate and, when you add a host, whether that renewal is the one being served. This page is about that workflow.
Why 90 days changes the habit
A long-lived certificate can be tracked on a calendar. A certificate that lasts about 90 days will be replaced several times a year, often by an automated client. The dangerous moment is not the issuance. It is the gap between a successful issuance and a server that is still offering the previous certificate, or a load balancer that was not reloaded, or a second host that the client does not know about.
Certificate Transparency records the issuance. If the certificate is publicly trusted, it should appear in the logs the sources Certwatch reads. The not-after date on that row is when that issuance expires. The next renewal is a different row, with its own dates, even when the names match. Certwatch stores both once it has seen them. It does not collapse them into a single health bit.
What the logs will and will not show
You will see names, issuer, and expiry for issuances the log source returns. Subdomains of a domain you watch are included when the query asks for them, which the public checker and the demo both do. You will not see a private certificate that never went to a public log. You may miss a certificate that expired before the first successful read, because the primary source lists unexpired issuances. After Certwatch has stored a row, the row stays past expiry.
A renewal that was logged and never installed still looks healthy in a pure log view: there is a certificate with a later not-after. That is why the inventory alone is not a deployment check. The public checker is explicit about this. It shows the page of logs and a call to action to monitor the domain. It never opens a socket to the host to see which certificate answers.
Automated clients can also fail quietly. The previous certificate remains served until it expires, and the logs simply do not gain a new row. In that case the useful signal is the approaching not-after on the certificate you already have, not a missing future row. Expiry highlighting and, on a paid plan, alerts are how that signal leaves the page.
How to tell a logged renewal from a deployed one
Add the hostname and port under the domain on an account. The hostname has to belong to that domain. Implicit TLS is allowed on a short list of ports, and STARTTLS on another short list. A container completes the handshake and stores the leaf and chain. DNS is resolved inside that container. Private, loopback, link-local, and shared addresses are refused, so this is not a way to scan an internal network.
The endpoint page compares names, and when it can, fingerprint or serial, with the stored log rows. If a related row expires later than the certificate being served, the page says the renewal is not deployed. If they match and nothing related expires later, it says they match. Free includes a few manual live checks and does not schedule them. Pro and Team check each endpoint once a day. Certwatch still does not install the newer certificate.
Use the public checker first if you only want the logged dates for a name. Use the account when those dates should be kept, and add the endpoint when you need the deployment fact. The mozilla.org demo shows a logs-only inventory and is not a statement about how that organization renews anything. Certwatch is not affiliated with Mozilla.
A renewal checklist that stays small
Look the apex up and note the soonest not-after and the issuer. If several names expire on different days, the automation is not covering every name evenly. Add the domain to an account so the next renewal has a place to land even if you are not on the checker that afternoon. The checker cache lasts about a day and then only refreshes when someone asks again, inside the lookup cap.
Turn on email if someone should hear about 30, 14, 7, and 1 days, which on a 90-day certificate is a reasonable set of reminders rather than a single alarm on the last morning. Add Slack on Team if the reminder should hit a channel instead of, or as well as, a mailbox. Then probe the host that clients actually reach, which may be a CDN name or a load balancer rather than the origin you renewed.
Questions
Does Certwatch renew these 90-day certificates?
No. Certwatch records public issuances and can compare them with a served certificate. The renewal and the install still happen in your own client.
Why would the logs show a new certificate while the site shows an old one?
Issuance and deployment are separate. A new row in the logs does not reload a server, a proxy, or a second host.
Does the public checker connect to confirm the renewal?
No. Confirmation of the served certificate requires an endpoint on an account. The checker is logs only.
Look up a domain or start monitoring
The public checker reads one page of Certificate Transparency and does not connect to the domain. An account keeps the inventory. Alerts, when you want them, start on a paid plan.
Check a certificate Create an account
See pricing for what Free, Pro, and Team include. The mozilla.org demo is logs only and is not affiliated with Mozilla. Related: Renewed but not deployed · SSL certificate expiry monitoring · How expiry rows stay after the date.