Why Key Vault Doesn't Warn You Before a Secret Expires

Most teams find out a Key Vault secret expired the same way: something downstream stops working, someone starts pulling logs, and eventually the trail leads back to a connection string or API key that quietly passed its expiration date days or weeks earlier. It feels like a monitoring gap. It's actually a design limitation in Key Vault itself, and it's worth understanding exactly where the coverage ends before you build (or buy) something to close it.

What Key Vault actually tells you

Azure Key Vault does emit near-expiry events through Event Grid — CertificateNearExpiry, SecretNearExpiry, and KeyNearExpiry. That sounds like the problem is already solved. In practice, none of it reaches anyone until you build the rest of the pipeline yourself:

• Nothing is subscribed by default. Every one of those three event types requires its own Event Grid subscription, configured per vault. Out of the box, Key Vault fires an event into the void — there's no built-in destination unless you've created one.
• Certificates and secrets fire once. Once you have subscribed to it, the near-expiry event for a certificate or secret triggers a single time, roughly 30 days before expiration. Miss that one notification — a dropped webhook, a misconfigured subscription, a team member who left before it was documented — and there's no second warning before it actually expires. Keys are the exception: near-expiry timing for keys can be configured through a key rotation policy, but that policy still has to be set up per key.

What it takes to actually cover this

Closing the gap yourself means more than "turn on an alert." It means wiring an Event Grid subscription per event type, per vault — three subscriptions for a vault holding certificates, secrets, and keys — handling the fact that new vaults get added over time and each one needs the same wiring repeated, and building somewhere for the results to actually show up — a dashboard, a digest email, something a human will look at before the expiration date, not after. And because most of these events only fire once, there's no safety net if that single notification gets missed.

None of that is exotic engineering. It's also not nothing — it's a real, ongoing maintenance surface for a problem that's easy to deprioritize until the week it causes an outage.

The gap widens as you scale

A single vault with a handful of secrets is manageable by memory. The problem compounds with every additional vault, every additional environment, and every team member who doesn't know a given secret exists, let alone when it expires. Organizations running Key Vault across multiple subscriptions — dev, staging, prod, per-team isolation — are usually the ones who get burned first, simply because there's more surface area and less shared visibility into what's rotating when.

If you're already paying for full observability

Teams already running a platform like Datadog with custom Key Vault integrations may already have this covered — that's a fine reason to stop reading here. This gap matters most for teams running Key Vault in production without a five- or six-figure observability contract behind it, which is a lot of teams.