At 19:05 CET on 31 August, Microsoft 365 stopped working for most of the world. Exchange Online, Outlook, Teams, SharePoint, ActiveSync and Defender XDR all went with it. The error users saw was "something went wrong". The error the backend logged was more useful: "The cert with thumbprint 19F04B8A… is expired".
Microsoft tracked it as EX1464935 and called the cause an "authentication component". The fix went out in stages over the following day. Nobody outside Redmond knows why that certificate was not renewed. What is known: one certificate was not renewed, and the first people to notice were the ones trying to send email.
The same failure, 5 days later, with a written post-mortem
On 5 September a homelab operator's wildcard certificate expired. His own issue on GitHub says what happened next better than I can:
The renewal had been failing since 2026-09-03 - every 30 minutes, for three days - and the first signal was a browser TLS warning.
Two things made it invisible. There was no alert on certificate expiry at all, even though cert-manager was exporting the metrics. And the certificate object reported Ready=True the whole time, while a separate Issuing condition sat stuck. From his proposed fix:
Something covering a Challenge stuck pending for hours, which is the actual leading indicator.
The expiry date is the last signal. The renewal that did not happen is the first one, and it arrives weeks earlier.
An expiry alert is a countdown, and a countdown cannot say the renewal is late
Every monitoring tool, ours included until today, works from the expiry date: 30 days, 14 days, 7 days, 1 day. It says nothing about whether the renewal was supposed to have happened already.
On a 90-day certificate the automation normally renews at day 60, so by the time a 30-day alert fires the renewal is already a day late and nobody has said so. On the 45-day certificates Let's Encrypt has been issuing on its tlsserver profile since 13 May, a 30-day alert fires the day after issuance and the 14-day one is already 2 weeks late. The default classic profile moves to 64 days on 10 February 2027 and to 45 days on 16 February 2028 - so the countdown model gets worse on a schedule.
The workaround the tools teach is to guess. UptimeRobot's own video puts it plainly: "if your server auto renews 14 days before expiry, you can set the reminder for 8 days out instead". That is asking you to know when your automation should have run and to keep the reminder in step with it by hand.
What we shipped today: we ask the CA when it wants the renewal, and tell you when that passes
Let's Encrypt publishes, for every certificate it issues, the window in which it wants that certificate renewed. It is a public endpoint, keyed on 2 fields inside the certificate itself. It needs no account and no agent. Google Trust Services does the same. The standard is ACME Renewal Information, RFC 9773, and it exists because a countdown was never enough for the CA either - it is how they tell clients to renew early ahead of a revocation.
CertPost now reads that window for every certificate it watches and does 2 things with it.
1 - "Renewal is late". The CA's window has closed, a fresh check shows the host still serving the same certificate, and you get told, with the cause in the subject line: your CA asked for this by the 16th and it did not happen. On a 90-day certificate that lands about a month before expiry. On a 45-day one, about 2 weeks before.
2 - "Your CA wants this replaced now". If the CA pulls the window forward to the present - which is what they do before a revocation - you hear within hours, whether or not your ACME client has ever heard of ARI. In Let's Encrypt's September 2024 incident, 133,613 certificates were given 5 days and 5.6% of them renewed through ARI. The rest found out by email or by outage.
For CAs that do not publish a window, we expect renewal at two thirds of the certificate's life, which is what every ACME client does, and we say nothing at all about long certificates that get renewed by hand - there is no schedule to be late against.
It is on every plan, including the free one, because it makes the alert you already get say something useful. And the free checker now shows the CA's window for any site you paste in, next to the expiry date.
3 things to do this week
1 - Run the free check on the hosts that would hurt. If the Renewal line is red, your automation is late and you have found out before your users did. For anything you suspect is renewed by hand, the 47-day readiness check says so, and counts what the falling lifetime ceiling turns that into.
2 - Check whether your ACME client asks the CA. certbot has done it since 4.1.0, Caddy and lego do it, win-acme does it. acme.sh and cert-manager do not, which is why the homelab above never heard a thing - if you are on either, put a renewal watch in front of it.
3 - If you run cert-manager, add the 3 rules from that GitHub issue - expiry within 24 hours, Ready=False held for an hour, and a Challenge stuck pending - because the last one is the leading indicator and the other 2 are the countdown.
Microsoft will publish a post-incident review at some point. It will say a renewal did not happen and a dependency was not understood, which is what the homelab issue already said on 5 September. Run the check on the hosts that would hurt, and if the Renewal line is red, fix the automation this week - the 7-day alert is the one you do not want to be your first signal.