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 and SecretNearExpiry. That sounds like the problem is already solved. In practice, the coverage is much narrower than the event names suggest:

• Certificates fire once. The near-expiry event 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 the certificate actually expires.
• Secrets and keys don't fire at all. There is no near-expiry event for secrets or keys in Key Vault today. If your API keys, connection strings, or encryption keys have expiration dates set, Key Vault will let them lapse silently — no event, no email, nothing.

What it takes to actually cover this

Closing the gap yourself means more than "turn on an alert." It means writing an Azure Function to poll every vault on a schedule (since secrets and keys emit nothing to subscribe to), wiring an Event Grid subscription per vault for the certificate case, 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.

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.