Every other failure in production arrives unannounced. A dependency falls over, a config change does something unexpected, traffic goes somewhere nobody modelled.
Certificate expiry is not like that. The date is printed on the certificate. It has been sitting there since the day it was issued, machine readable, in a field designed for exactly this purpose.
And it still takes companies down, regularly, in 2026.
I find that genuinely interesting, because it means the problem is not detection. You cannot argue that the signal was missing. It means the failure is somewhere else entirely.
The number that gives it away
Keyfactor's 2026 research found that certificate outages typically pull 11 to 20 people in to resolve.
Eleven to twenty. For a renewal.
That number is not describing a hard technical problem. It is describing a search. People are being pulled in because nobody knows which certificate it is, where it is deployed, who issued it, or who is allowed to replace it. The technical fix takes minutes once you find the right person. Finding the right person is the outage.
The same write-up lands on the conclusion that keeps appearing in these reviews: the certificate was not unknown. It just was not anyone's clearly assigned job to renew.
That is an ownership failure wearing a cryptography costume.
Where they actually hide
Public-facing websites are mostly fine. Somebody notices, somebody owns the domain, it is in a dashboard.
The ones that cause trouble are the ones nobody inventories: internal service-to-service certificates, monitoring and security appliances, third-party vendor integrations, device fleets, and shared wildcard certificates covering a set of backends that has drifted since the certificate was issued.
The wildcard case is the one I would look at first. A single certificate covering many services means a single expiry taking out many services at once, and the list of what it covers is rarely written down anywhere near the certificate itself.
There is a worse variant, and it has a well-known example. An expired certificate on an internal monitoring pipeline does not look like an outage. Everything appears to keep running. What has actually happened is that the system meant to tell you about problems has quietly stopped being able to. At Equifax, a certificate feeding a monitoring pipeline expired and disabled inspection that would have surfaced a breach in progress.
That is the shape worth being scared of. Not the site going down. The safety net going down without a sound.
The frequency is about to increase eight fold
Whatever your current process is, it is about to be tested far harder than it has been.
In April 2025 the CA/Browser Forum voted to shorten certificate lifetimes on a schedule. The rollout runs in three steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, down from a ceiling of about 398 days.
The first step already happened. Since 15 March 2026, newly issued public TLS certificates max out at 200 days. If you renew annually, that change has already landed on you.
One analysis puts the breaking point clearly: March 2027 is where manual renewal stops being viable for any fleet above roughly twenty certificates. At 100 days you are renewing three or four times a year per certificate. An annual calendar reminder cannot survive that, and quarterly is not frequent enough either.
Domain validation reuse shrinks alongside it, down to 10 days by 2029, which removes the shortcut of validating once and reissuing cheaply for a year.
The reasoning behind the change is sound. Shorter certificates shrink the window in which a compromised key is useful and reduce dependence on revocation, which has never worked well. But the practical effect is that a process which mostly worked at annual frequency will fail at eight times that rate, and it will fail in the same place it always did, which is ownership.
Two systems, one gap
Here is the specific thing I would go and check on your own setup.
You almost certainly have some form of certificate expiry monitoring. Most teams do, even if it is just an uptime check that shouts when TLS breaks.
You also have some notion of service ownership somewhere. A tag, a catalogue, a wiki page.
The question is whether those two things are connected. When an expiry alert fires, does it arrive with a team attached, or does it arrive as a hostname that somebody now has to trace back to a service, to a team, to a person who is awake?
That gap is where the eleven to twenty people come from.
This is a large part of why Vörr and Shankh are separate things that share the same picture. Vörr can find what actually exists across your cloud accounts and how it relates to your services, so a certificate on a load balancer is connected to the service behind it and the team that owns that service. Shankh takes an alert and gets it to that named person on a channel they will see, escalating if they do not respond.
An expiry warning routed to a mailbox nobody reads is not monitoring. It is a record that you were told.
What I would do this quarter
Build the inventory from the infrastructure, not from a spreadsheet. Enumerate what is actually deployed across your cloud accounts and load balancers, plus certificate transparency logs for anything public. A hand-maintained list is exactly what is already failing you, and it will be missing the ones that matter.
Check whether every certificate maps to a service, and every service to a person. Not a team name. A rotation. This single link is what turns a twenty-person scramble into one page to one owner.
Alert on a schedule, not a threshold. Thirty days, fourteen, seven, one. A single warning is a message somebody was on holiday for.
Automate before 2027 rather than after. ACME and the tooling around it are mature and boring, which is what you want. The forcing function arrives in March 2027 whether or not anyone has prioritised it.
Then find your wildcards and write down what they cover. That list does not exist right now, and you will want it before the renewal rather than during the incident.
The strange thing about this failure is that it is the one place where the infrastructure has already told you exactly when it will break. Everything else you have to predict. This one you just have to read, route to a person, and act on, which turns out to be the hard part.
Author note
I have come to think of this as a useful diagnostic for a team rather than a task.
If an expiry alert can find its way to a named human without anybody having to work out who that is, your ownership data is real. If it cannot, then your ownership data is a document, and this is simply the failure that happens to expose it first.
There will be others. This one just arrives with a date on it.
Mohan Gopi, Associate DevOps Engineer at Frigga Cloud Labs, working across AWS, GCP and Azure. LinkedIn.