---
title: "What a repair script cannot see in a 90-day certificate renewal cycle"
canonical: https://dxdev.com/blog/the-batch-aging-out-with-no-alarm/
datePublished: 2026-08-06
---
Nearly a thousand of our TLS certificates for customer-facing sites were sitting on a validation method that needed a fresh DNS record from the customer's own domain every 90 days, and nothing in place would have noticed a specific one about to fail before the renewal actually did.

## A migration default nobody chose

Months earlier, a [one-time bulk migration onto a CDN's managed-certificate product](/blog/956-certificates-needed-a-customer-to-renew/) had registered close to a thousand hostnames using the older of two validation methods. That method checks a special record sitting in the customer's own DNS. Every hostname added since had gone in on the newer method by default, the kind the CDN answers itself at its own edge, with no DNS record required from anyone.

Nobody picked the older method on purpose for that batch. It was what the migration tooling happened to write. It kept working for months, because a certificate on that method only needs the DNS record present at the moment it renews.

## Why our repair script stayed quiet

We already had a script that watches for certificates stuck mid-renewal and repairs them automatically. It only acts on a hostname it can already see failing, one sitting in a stuck or timed-out state. A hostname on the older method that hasn't reached its 90-day mark yet doesn't look stuck to anything. It looks like every healthy certificate, right up until the DNS record it needs is gone and the renewal fails.

## How the batch showed up

The CDN surfaced it, sending "action required" notices as each 90-day window approached. Reading a handful of those closely showed the shape of it. This was a batch, all sharing the same migration origin, all coming due around the same season.

## The flip

Every hostname on the old method got switched to the new one in a single pass. Zero of the flips failed. Afterward the whole estate sat on the method that needs nothing from any customer at renewal.

## Two tools, two jobs

The reactive script and the flip solve different problems, and neither replaces the other. The script repairs a renewal that has already broken. Nothing before this noticed a batch approaching that break before any of it hit.

So we built a watchdog alongside the fix. It reads the whole estate on its own schedule and speaks up in three cases: a certificate is close to expiring without a completed renewal, a hostname has drifted back onto the old method, or an onboarding never got a certificate at all. We no longer depend on a vendor's warning email, or a customer noticing first.

A system can look healthy for a long time running on repair alone. The certificates that had renewed fine for months looked exactly like the ones that never would have, until the day one of them didn't.

## Two questions for whoever runs your certificates

Ask which validation method each hostname uses. Then ask what would warn them before a renewal fails, as opposed to after. A repair script only helps once a certificate is already stuck. A scheduled check across the whole estate is what catches a batch on the older method, or a hostname that never got a certificate, before a customer sees it.