Monitoring Short-Lived TLS Certificates with Semonto

How Semonto helps you stay in control when using short-lived Let's Encrypt certificates, including smart alerting and dead man switch monitoring.

Jelle De Laender 18 January 2026

Short-lived TLS certificates are here

TLS certificates used to be valid for multiple years. In recent years, the maximum lifetime was reduced to about 13 months, and Let's Encrypt popularized the 90-day model. For more background on why lifespans keep shrinking, see our post on why TLS/SSL certificates get shorter lifespans and how to prepare for them.

With the introduction of short-lived certificates, validity is reduced to just a few days. Let's Encrypt recently announced support for certificates with a lifetime of around six days.

Short-lived certificates improve security by design:

A leaked or compromised certificate becomes useless very quickly
There is far less reliance on revocation mechanisms that are often ignored by clients
Automated renewal becomes the default, not an optional best practice

There is a trade-off. Automation becomes mission-critical. If renewal fails, you no longer have weeks to notice and react. You might have hours.

That is exactly where monitoring matters.

The operational risk of short-lived certificates

Short-lived certificates change the operational model:

Renewal jobs run more frequently
Any failure in DNS, Automated Certificate Management Environment (ACME) challenges, file permissions, or service reloads has a faster impact
A silent cron failure can break production without immediate visibility

This means two things must be monitored:

The certificate itself
The renewal process that keeps it alive

Semonto supports both.

Monitoring certificate expiration with Semonto

Semonto continuously checks your TLS certificates and alerts you before they expire.

For short-lived certificates, the default notification windows are usually too late. Instead, you should configure tighter alert thresholds.

Recommended alert settings for short-lived certificates

Semonto allows you to configure when certificate expiration alerts are sent. You can set these thresholds per monitor, and you can also change the global defaults for all new monitors. This is described in detail in the HTTPS certificate monitoring documentation and the guide on how to monitor your TLS/SSL certificates.

For short-lived certificates, a practical setup is:

First warning: 2 days before expiration
Second warning: 1 day before expiration

This gives you enough time to investigate automation issues while still respecting the short validity window.

It also aligns with Certbot's renewal timing for short-lived certificates. If renewal starts at about 3 days and 8 hours before expiration, a first warning at 2 days introduces a 32-hour grace period before alerting.

That reduces false positives from temporary renewal delays and still leaves about 48 hours to fix issues before expiration.

You can adjust these settings via the "Change the default notification days" option in your Semonto account, or by editing your monitor in Semonto under Monitor -> TLS/SSL certificate -> Settings.

This setup ensures that even if automation partially fails, you are alerted before users are impacted.

Monitoring the renewal process itself

Certificate monitoring answers the question:

"Is my certificate still valid?"

It does not answer:

"Did my renewal job actually run today?"

With short-lived certificates, that second question becomes just as important.

This is where Semonto's cron job monitoring feature becomes a powerful safety net.

Using Semonto as a dead man switch for certificate renewals

Semonto cron monitoring follows a simple principle:

Your system sends a success signal when a job finishes correctly
If Semonto does not receive that signal in time, it alerts you

This pattern works especially well for certificate automation.

Instead of reporting failures, the renewal process reports success. Missing signals are treated as failures automatically.

For short-lived certificates, run renewal checks multiple times per day and alert quickly when a check-in is missed.

How this works in practice

The renewal flow typically looks like this:

A scheduled job runs periodically
When the certificate is about to expire, the renewal tool attempts to renew the certificate
The web server reloads its configuration if needed
A final check confirms the live certificate is still valid long enough
Only then is a success signal sent to Semonto

Data flow of the certificate renewal process with Semonto check-ins

Open full size in a new tab
The key point: Semonto only receives a success check-in after renewal, reload, and validation all succeed.

If any of these steps fail, no signal is sent. Semonto alerts you because the expected check-in never arrived.

This approach detects:

Renewal command failures
Web server reload issues
Certificates renewed but not activated
Cron jobs that stopped running entirely

Certificate renewal thresholds (Certbot / Let's Encrypt)

Certbot documents the renewal threshold like this:

"As of Certbot 4.0.0, a certificate is considered ready for renewal when less than 1/3rd of its lifetime remains. For certificates with a lifetime of 10 days or less, that threshold is 1/2 of the lifetime. Prior to Certbot 4.0.0 the threshold was a fixed 30 days."
Source: Certbot User Guide

These thresholds are specific to Certbot. Other ACME clients may use different renewal logic.

In practice, this means that default 90-day Let's Encrypt certificates are renewed when less than 30 days remain. For short-lived certificates, the same logic scales down: a certificate valid for about 160 hours (around 6 days and 16 hours) is renewed when less than 80 hours remain (about 3 days and 8 hours).