6-Day Certificates 2026: Recalibrating SSL Monitoring

What 6-day certificates are - and why they are coming

A 6-day certificate is a regularly trusted TLS certificate whose validity is capped at 160 hours - just over six days (Let's Encrypt). It is obtained through the shortlived profile in an ACME-capable client such as Certbot or acme.sh; everything else works as with an ordinary certificate. In parallel, Let's Encrypt introduced certificates for IP addresses: these are mandatorily short-lived and likewise valid for only 160 hours, because ownership of an IP can change faster than that of a domain (Let's Encrypt). Both variants cover IPv4 and IPv6 (Let's Encrypt).

The point of the short lifetime is security: the shorter a certificate is valid, the smaller the window in which a compromised key can be abused - and the less security depends on sluggish revocation mechanisms such as CRL or OCSP (Let's Encrypt). Let's Encrypt issued its first six-day certificate back in February 2025, with general availability following almost a year later (Help Net Security). The direction is unambiguous: in late 2025, Let's Encrypt announced it would also cut its standard lifetime from 90 to 45 days (Let's Encrypt). Short-lived certificates are therefore no longer a niche experiment but the new default that operations should prepare for.

The industry trend: from 398 to 47 days

Let's Encrypt's short-lived certificates are merely the spearhead of a movement sweeping the whole industry. The CA/Browser Forum - the body of certificate authorities and browser vendors - passed ballot SC-081v3 in April 2025 by 29 votes to 0 (CA/Browser Forum). It cuts the maximum permitted lifetime of publicly trusted TLS certificates in three steps: from 398 days to 200 days from 15 March 2026, to 100 days from 15 March 2027 and finally to 47 days from 15 March 2029 (CA/Browser Forum). In parallel, the reuse period for domain control validation (DCV) shrinks to ten days by 2029 (CA/Browser Forum).

The practical effect: manual certificate renewal is on its way out. Anyone swapping a certificate by hand every 47 days - let alone every two days - loses that race. ACME automation is the only viable answer, and with automation the operational risk shifts from the human to the machine. That is precisely why monitoring has to move too: away from the calendar entry, toward continuous control of the renewal chain.

For small and mid-sized businesses this does not mean becoming a certificate authority yourself. Most hosts and reverse proxies already renew certificates automatically via ACME. What matters is that someone keeps an eye on whether that automation actually works - especially when it sits in someone else's hands and you have no direct view of the renewal job. External monitoring takes on exactly that oversight without you needing access to the server or the ACME client.

Why classic expiry alarms fail on short-lived certificates

For years SSL monitoring was simple: you set a warning 30 or 14 days before expiry, and a human swapped the certificate in time. That model assumes months of runway. For a certificate with 160 hours of validity, a 14-day threshold is useless - the certificate does not even exist that long. Such a rule would raise an alarm permanently and, in practice, ends up where over-firing alarms often end up: muted.

With short-lived certificates the failure mode also shifts. The typical cause of an outage used to be: someone forgot to renew the certificate. Today it is: the automation quietly stopped doing its job. A halted cron job, an expired API access or a failed challenge goes unnoticed at first because no human is actively in the process anymore. The monitored signal must therefore be the renewal process, no longer the expiry date alone. The same holds for domains - as the piece on preventing domain expiration shows, it is often the silent automations that break.

What actually needs monitoring on short-lived certificates

Anyone running short-lived certificates monitors a rhythm, not a date. Four signals together give a robust picture of the renewal chain's health.

None of these four signals is enough on its own. A fresh notBefore date says little if the renewal job only happened to run this once; a green sign of life is worthless if the job starts but issuance is refused. Only the interplay of rhythm, job control, remaining share and endpoint inventory reveals whether the whole chain is healthy. It is important to treat every served hostname and every certificate individually - a wildcard certificate and a separate API endpoint can behave completely differently even though they belong to the same domain.

Tie warning thresholds to the lifetime

The most robust rule is: set thresholds relative to the lifetime, not in absolute terms. Let's Encrypt recommends renewing a short-lived certificate at roughly half its lifetime and running the ACME client at least once a day (Let's Encrypt). The basis for this is ACME Renewal Information (ARI): the certificate authority tells the client when to renew, and ARI-based renewals are exempt from Let's Encrypt's rate limits (Let's Encrypt). Since September 2025 ARI has been standardized as RFC 9773 (IETF).

For monitoring, the same logic fits into a small policy: one warn and one critical threshold per lifetime class, plus a rule that catches an overdue renewal. The following example is meant as a guide value and should be adapted to your own environment:

{
  "ssl_thresholds": [
    {
      "cert_lifetime_days": 90,
      "warn_days": 30,
      "critical_days": 7
    },
    {
      "cert_lifetime_days": 6,
      "warn_hours": 48,
      "critical_hours": 24
    }
  ],
  "renewal_watch": {
    "expected_renewal_every_hours": 60,
    "alert_if_cert_age_exceeds_hours": 84
  }
}

The last rule is the crux: if the age of the served certificate exceeds 84 hours although the automation should renew roughly every 60 hours, something has broken - and with enough buffer to intervene before the 160-hour expiry. In XICTRAQ the warning thresholds are freely configurable (by default 14 days before expiry, critical from three days), so you can pull them down to hours for short-lived certificates instead of working with a preset intended for long-lived ones.

The check interval is part of the threshold too. Checking a certificate with 160 hours of validity only once a day can, in the worst case, let almost a whole day pass before a break is noticed - a lot when the buffer is only a few days. As a rule of thumb, the check interval should be markedly shorter than the remaining reaction window. For short-lived certificates that means several checks per day rather than a single nightly run, so no more time than necessary elapses between break and alert.

When the ACME automation breaks: the hours trap

Because only hours separate the last valid renewal from an outage, the silent failure of the automation is the central risk. The most common causes of a stalled renewal:

• The scheduled job was disabled, moved or not re-established after a server migration - the classic silent failure.
• Rate limits kick in, for instance when RSA and ECDSA certificates are obtained in parallel and requests double; ARI-capable clients are exempt from this (Let's Encrypt).
• Domain validation fails because a DNS record was changed, a firewall blocks the HTTP-01 challenge, or a reverse proxy reroutes the validation path.
• The ACME account has expired or the External Account Binding (EAB) has become invalid - the client checks in, but issuance is refused.
• Operational edge cases such as a full disk, a skewed system clock or an expired client token prevent writing or requesting the new certificate.

The common denominator: the server itself keeps running, only the renewal does not. A purely local check on the same system can share that blind spot. That is why control belongs on the outside - combined with classic uptime monitoring, so that an outage that does occur is spotted at once. That third-party dependencies become an underestimated source of failure here is shown by the piece on cloud outages and third-party dependencies.

How costly the blind spot is, the numbers show: according to the 2024 PKI and Digital Trust report, 88 percent of organizations recorded unplanned outages from expired certificates (Keyfactor), on average more than three certificate-related outages within two years (Keyfactor). A separate survey sees 40 percent of enterprises at risk of an outage from expiring SSL certificates (CSC). With shorter lifetimes the number of renewals grows - and with it the number of occasions on which something can go wrong.

Monitoring short-lived certificates externally with XICTRAQ

XICTRAQ checks the certificate actually being served on a regular basis from an external vantage point: expiry date, certificate chain and configuration, plus detection of weak cipher suites and misconfigurations. The warning thresholds are freely adjustable and can thus be tied to the lifetime - in days for long-lived certificates, in hours for short-lived ones. For Let's Encrypt certificates, SSL certificate monitoring additionally detects failed renewals - exactly the silent automation break that takes short-lived certificates down within hours.

Because a single server can serve several certificates - for the main domain, for subdomains, for IP-bound services - XICTRAQ treats each of them as its own monitored object with its own history. That surfaces even the case where the main certificate renews dutifully while a secondary service with its own automation has been sitting on the same old certificate for days, quietly drifting toward expiry.

To turn a measurement into an early-warning system, XICTRAQ combines the certificate check with multi-channel alerting, with domain and DNS monitoring and with reports and status pages that document the renewal trajectory over weeks. Anyone also watching domain expiry should account for the WHOIS sunset - the piece on RDAP instead of WHOIS explains why. So you see not only that a certificate is still valid, but also whether it renews at the expected cadence.

Start with a free trial and check how your certificates renew today. Or book a personal demo to see lifetime-tied thresholds and the detection of failed renewals in action.