How do you track API keys, tokens, and signing certificates that quietly expire?

The credentials that expire without a bill

Domains and subscriptions come with an invoice, which is a reminder in disguise. Credentials do not. The expiry is chosen at creation, often by a developer who picks one year or two because the form asked, and then the credential disappears into a configuration file. Common examples include cloud access keys under a rotation policy, OAuth client secrets, personal access tokens used by continuous integration, identity provider signing certificates used for single sign-on, mobile push notification certificates, code signing certificates, webhook signing secrets, service account keys, and VPN or SSH certificates. Related: How to Build a Single Calendar for All Your Expiries

The failure is always abrupt and rarely near anyone's attention. A deployment pipeline fails on a Tuesday because the token that pushes to the container registry was created twenty-four months ago. Every employee is locked out of every app at once because the signing certificate on the single sign-on integration rolled over at midnight. Push notifications stop for a mobile app and nobody notices for a week. None of these produce a bounced payment or a warning letter.

Keep reading: The Hidden Cost of a Missed Renewal, Never Lose a Domain Again: A Simple System, SSL Certificate Expiry and How to Stay Ahead. See how LatePinger helps you expiry reminders for domains, ssl, and renewals.

Build the inventory from where the secrets live

Do not try to build the list from memory. Go to the places credentials are stored and issued. A secrets manager or vault can usually list every secret with its metadata. The identity provider admin console shows each application integration and the expiry of its signing certificate. Continuous integration settings list stored tokens. Cloud providers offer credential reports that show every access key and its age. Mobile developer portals list certificates and provisioning profiles. A search across code repositories for words like expires and token catches the rest. Related: SSL Certificate Expiry and How to Stay Ahead

For each credential record what it is, where it is used, who owns it, when it expires, how to rotate it, and what breaks if it fails. That last column, the blast radius, is what decides the lead time. Wherever the platform supports it, prefer short-lived credentials that are issued and rotated automatically, because a credential that rotates itself every hour never needs a reminder. The inventory is for everything that cannot work that way. Related: Setting Lead Times That Actually Give You Room

Rotation is the real task, expiry is only the date

Renewing a credential is rarely a single click. A new signing certificate for single sign-on has to be generated, then uploaded to both the identity provider and the application, and then activated in a coordinated cutover. Some platforms allow two certificates to be valid at once, which gives you an overlap window; others switch instantly, which means a maintenance window. Code signing certificates have to be distributed to every build machine. API keys have to be replaced in every environment that uses them, including the staging environment nobody remembers.

Because of this, lead times for credentials should be longer than for domains. A reminder at sixty days, another at thirty, and a final one at seven works for anything that requires coordination with another team or another company. Write the rotation runbook at the moment the credential is created, when the person doing it still remembers every step, and test the rotation in staging before doing it in production. A runbook written during an outage is a very different document.

Making the dates visible to non-engineers

Engineers own the rotation, but the dates should not live only in engineering heads. Put credential expiries into the same reminder system that tracks domains and contracts, with a team alias as the owner and the engineering manager as the second recipient. That way a departure inside the team does not orphan the date, and the person who reviews domains each quarter sees the certificates on the same list.

Use monitoring where you can and reminders where you cannot. A signing certificate published in identity provider metadata and a TLS certificate can both be probed from outside and alerted on automatically. An API key's expiry is invisible from the outside until the first failed call, so it has to be tracked by date. The combination of an inventory, monitoring for the probeable items, and dated reminders for the rest is what turns credential expiry from an outage into a scheduled task. Related: The Hidden Cost of a Missed Renewal