The warning threshold for the "SSL / HTTP" check does not match ACME certificates

Another one of those "extremely important" requests from me...

Summary:

By default, the check issues a warning 30 days before expiration (warnDays default 30, errorDays default 14). The widely used ACME clients renew their certificates exactly when there are 30 days remaining. So the warning doesn’t appear before a problem occurs, but rather regularly on the day before the scheduled renewal—every 60 days for a Let’s Encrypt certificate, for each endpoint.

Why 30 days is the wrong number

A Let’s Encrypt certificate is valid for 90 days. Renewal occurs when about one-third of the validity period remains: Certbot renews with 30 days remaining, acme.sh after 60 days, Caddy at one-third of the total validity period, Traefik 30 days before expiration, and win-acme after 55 days. The default setting for the check is therefore set to the same day as the renewal.

In my setup, I monitor 69 endpoints across 11 assignments, mostly Let’s Encrypt (and the number is rising as I’m increasingly switching to API-based, DNS-authorized renewals with LE certificates). Today, two of them were again flagged as warnings with 29 days remaining—both will renew automatically in the next few days. This isn’t an isolated incident—it’s the norm—and it’s the kind of notification that renders a monitoring channel useless: It’s always there, it’s always unfounded, and eventually you stop noticing the real ones.

A warning only constitutes useful information if the automatic renewal has not taken place. ACME clients attempt renewal daily. With 21 days remaining, at least nine attempts have failed—that’s a finding. With 30 days remaining, it’s just normal operation.

The fixed daily threshold is expiring anyway

With Ballot SC-081v3, the maximum validity period for public TLS certificates is gradually decreasing: 200 days starting March 15, 2026; 100 days starting March 15, 2027; 47 days starting March 15, 2029. A 100-day certificate is renewed when approximately 33 days remain—the 30-day warning is then permanently within the renewal window. For a 47-day term, it takes effect immediately upon issuance. An absolute number of days as the sole parameter thus has an expiration date.

Suggestion:

• Lower the default to 21 days (warnDays 21, errorDays 7). This is a minor change that takes effect immediately for all new assignments and no longer affects common ACME clients.

• Threshold per assignment instead of per endpoint, with optional deviations at individual endpoints. Currently, `warnDays` is set in every endpoint object. For an assignment with 24 endpoints, a correction would require opening 24 entries and changing them individually. Via the API, this was a script; in the interface, it takes half an hour.

• Alternatively or in addition, a relative threshold —a warning at X percent remaining time instead of X days. This is the variant that withstands the reduction in runtime without requiring further readjustment: 20 percent remaining is 18 days for a 90-day term and 9 days for a 47-day term—in both cases, well past the renewal date.

Point 1 alone solves the day-to-day problem. Point 3 solves it permanently.