TokenTimer

When we started building TokenTimer, the problem looked pretty simple.

Teams have certificates, API keys, secrets, licenses, subscriptions, and other things that expire. The dates are usually scattered across different tools, cloud providers, secret managers, spreadsheets, calendars, and scripts.

So the first thing we built was visibility.

Put everything in one place, assign an owner, and send alerts before something expires.

That made sense, but after working more deeply on certificates, we realized visibility only solves part of the problem.

Knowing that a certificate expires in 14 days is useful, but somebody still has to renew it, deploy the replacement, reload the service, and check that the new certificate is actually being served.

If one of those steps gets missed, you can still have an outage even though the monitoring worked perfectly.

That changed how we thought about TokenTimer.

We started building CertOps so the certificate lifecycle could continue beyond the alert. Renewal, deployment, service reload, and verification can happen through an agent running inside the customer’s infrastructure.

We also made one architectural decision quite early: TokenTimer’s control plane should not need access to private keys.

Operations that involve private keys stay inside the customer’s environment. The agent only needs outbound HTTPS communication with TokenTimer.

That lets us automate more of the certificate lifecycle without asking teams to hand their private keys to another control plane.

We also open-sourced TokenTimer Core under AGPL-3.0. It can be self-hosted with Docker Compose or Kubernetes and Helm, and there is also a hosted version.

Certificates are only one part of TokenTimer. We still track API keys, secrets, licenses, subscriptions, and other time-bound assets.

But working on certificates changed the way we see the overall problem.

Monitoring is useful because it tells you something needs attention.

What we really want is to remove as much of that manual attention as possible before an expiration turns into an incident.

I’m curious how other teams handle this today.

For certificates in particular, does your automation go all the way from renewal to deployment and verification, or are there still manual steps somewhere in the process?