Key takeaways
- Gemini API keys have no built-in expiry, so failures usually mean revocation, quota limits, or billing issues rather than a timestamp.
- GitHub requires an expiration date on every fine-grained personal access token, with a maximum custom date one year out, and org policies can shorten it further.
- HashiCorp Vault enforces deadlines through token TTL and explicit_max_ttl, while periodic tokens renew indefinitely for service accounts.
- Salesforce refresh tokens do not expire on a timer by default; they die on revocation, policy change, or a configured validity window.
- Vaults store secret values but rarely track ownership, expiry, and rotation deadlines for external SaaS keys, which is the gap credential tracking fills.
Credential tracking means recording, for every key and token you run, who owns it, when it expires, and what the rotation deadline is. Expiration mechanics differ sharply per platform: GitHub fine-grained tokens, Vault tokens, AWS access keys, Gemini API keys, and Salesforce refresh tokens each control expiry differently. This guide covers the exact settings for each of the seven, and what metadata to record.
What does credential tracking actually involve?
Credential tracking is monitoring three things for every non-human credential you run: who owns it, when it expires, and when its rotation deadline lands. It is not the same job as storing secret values. Your vault (AWS Secrets Manager, Vault, Infisical) holds the value; tracking covers the metadata around it, which is usually where the gaps are.
The distinction matters because vaults answer "can this workload fetch the key?" while tracking answers "whose key is this, when does it die, and who gets paged?" Even Google's own Gemini API guidance on creating and restricting API keys leaves expiry and ownership to you to record.
Once credentials span AWS, Stripe, and GitHub, that metadata lives in someone's spreadsheet. Alternatives to manual credential rotation tracking exist for teams that outgrow it.
How does expiration work for Google Gemini API keys?
Gemini API keys are created in Google AI Studio, not the Cloud Console, and they carry no built-in expiry date. A key stays valid until you delete it, until the underlying Google Cloud project hits quota or billing limits, or until Google restricts it for policy reasons. That means "gemini api key expired" usually points to a revoked key, a disabled project, or a rate/billing failure rather than a timestamp you can look up.
Where Gemini keys are created and deleted
You generate and revoke keys under "Get API key" in AI Studio, scoped to a Google Cloud project. Because there is no expiry setting, your rotation policy is whatever you enforce externally. Record the creation date, owning project, and owner (e.g. "Platform engineering") when you create one, and track rotation deadlines yourself — the same metadata-only approach covered in https://keyguardrail.com/blog/how-to-track-api-key-expiry.
Recovering from an expired or revoked key
If calls start returning 403 or 400 errors, check whether the key still exists in AI Studio and whether the project's billing is active. The fix is to create a replacement key, swap it into your vault (Secrets Manager, Infisical, or wherever it lives), and delete the old one so the audit trail is clean. Humans copying the new key by hand is exactly the transport-layer problem worth removing: update the secret in the vault, let workloads pull from there, and log who changed what.
Can GitHub fine-grained tokens have no expiration?
No. GitHub requires an expiration date on every fine-grained personal access token; the maximum is one custom date up to one year out, so the github fine grained token no expiration question resolves to "you can pick the longest allowed window, but never none."
Expiration options when creating a fine-grained token
When creating the token you choose 7 days, 30 days, 60 days, 90 days, or a custom date. GitHub emails you before expiry, but email is not an ownership record: if the token belongs to a deploy pipeline or a departed engineer's account, the notification goes nowhere useful. Record owner, expiry date, and the resources it touches at creation time.
Organization token policies that override your choice
Org owners can cap fine-grained PAT lifetime or block them entirely under personal access token policies, so your one-year token can be cut short by policy. Track the policy, not just the token. KeyGuardRail monitors that metadata without holding the secret value itself, and our model and controls are described at KeyGuardRail security. Details on both settings are in GitHub's fine-grained PAT documentation.
How do you control HashiCorp Vault token expiration?
TTL, explicit max TTL, and renewal
Every Vault token gets a TTL set at creation, either by the auth method's role or a ttl parameter on the token call. The explicit_max_ttl caps how long that token can live even if renewed, so a 24h TTL with a 720h explicit max means 30 days of possible renewals, then a hard stop. Renewable tokens extend via vault token renew; non-renewable ones just die at TTL. For a 30/60/90 day rotation policy, the explicit max TTL is the setting that actually enforces the deadline, so record it as the credential's expiry date.
Periodic and service tokens for automation
Periodic tokens (period on the role) renew indefinitely as long as each renewal lands inside the window, which suits service accounts that must never expire but should still rotate. Batch tokens are the opposite: short-lived, non-renewable, no quota cost. The gap Vault leaves open is ownership metadata: who owns the token, which system consumes it, and what to do when the explicit max TTL hits. That audit trail lives outside the vault, which is where credential tracking like KeyGuardRail picks up, monitoring expiry metadata without holding secret values.
What settings govern IdentityServer4 token expiration?
IdentityServer4 exposes three knobs you set per client: AccessTokenLifetime, RefreshTokenLifetime, and RefreshTokenUsage. Access token lifetime defaults to 3600 seconds (one hour) and should be short, since the token is presented on every API call. Set it to 300–900 seconds for internal APIs and lean on refresh tokens for continuity.
Access token lifetime
AccessTokenLifetime is set in the client configuration object, either in code or loaded from your client store. Shorter is safer: a leaked access token is valid until it expires, with no server-side revocation path for JWTs unless you run a reference token setup. Pick a lifetime your API consumers can tolerate re-issuing via refresh.
Refresh token rotation and sliding windows
RefreshTokenUsage controls one-time use (OneTimeOnly) versus reuse; OneTimeOnly with RefreshTokenOneTimeOnly detection catches token replay. RefreshTokenLifetime sets the absolute cap, while SlidingRefreshTokenLifetime extends it on each use, up to that absolute limit. A common pattern: 30-day absolute lifetime with a 14-day sliding window, so active clients stay logged in and dormant ones re-authenticate.
Record each client's lifetime settings, last refresh, and next deadline in your credential tracking inventory. A short-lived-creds policy only works if someone knows when a client's refresh token hits its absolute cap. KeyGuardRail tracks those deadlines as metadata, without holding the secret value itself. For lifetimes across other providers, see these API key expiration policy examples.
How does the OpenShift service account token-expiration setting work?
Bound tokens and projected volumes
OpenShift uses bound service account tokens, which are tied to a pod, node, or service rather than floating forever. Tokens projected into pods via a projected volume default to a one-hour lifetime and are refreshed automatically by the kubelet as long as the pod keeps running, so a running workload never holds a stale credential. If the pod is deleted, the token becomes invalid, which is the short-lived-creds behavior most teams want by default.
Requesting custom token lifetimes
For tokens requested outside a pod, you set expirationSeconds in a TokenRequest; the API server caps this at the extended expiration configured on the cluster (86400 seconds by default on OpenShift). Record who requested each token, its audience, and its expiry in your credential tracking sheet, because nothing else will. The same discipline applies to Vault token TTLs, which are set per role or per token as described in the HashiCorp Vault token documentation.
How do you rotate AWS keys automatically?
IAM access key age and last-used data
IAM gives you two signals per access key: CreateDate and LastUsedDate (via iam get-access-key-last-used). Keys older than your 30/60/90 day rotation policy that show no recent use should be deleted, not rotated. Run this as a scheduled Lambda that lists keys per user, flags stale ones, and posts to Slack with an owner tag so someone knows which key is about to die.
Secrets Manager rotation lambdas
For RDS credentials and any secret stored in Secrets Manager, attach a rotation Lambda using one of AWS's built-in templates. Secrets Manager runs it on the schedule you set and stages the new value with a four-step create/test/finish/deactivate flow, so the old secret keeps working until the swap completes.
For keys AWS cannot rotate itself (Stripe, GitHub PATs), the practical pattern is the same Lambda scaffold but you call the vendor's rotation endpoint yourself. KeyGuardRail tracks the expiry dates and rotation deadlines for those keys as metadata only, without holding the secret values.
What is the Salesforce refresh token expiration policy?
Salesforce refresh tokens do not expire on a timer by default. They stay valid until revoked, which means your credential tracking problem is not an expiry date but an inventory problem: you need to know which connected apps hold tokens and who owns each one.
Connected app policies
Two policy levels control refresh token behavior. The connected app's own policy sets the refresh token validity period, and the org-level "Refresh Token Policy" under Session Settings can cap it for everything in the org. Admins can also require re-authentication via the "High Assurance" session policies.
When refresh tokens actually expire
A refresh token dies on revocation (user or admin action), on policy change, or when its configured validity window lapses. Record the issuing connected app, the owner, the policy setting, and the last-used date. The same lifetime-vs-revocation distinction is documented for other identity stacks too, including the IdentityServer4 documentation on token lifetimes.
Which credential tracking software fits a small team that already has a vault?
A vault stores secret values and controls access. It does not answer who owns a key, when it expires, or whether the 30/60/90 day rotation policy is actually being met across AWS, Stripe, and GitHub at once.
What a vault does and does not track
HashiCorp Vault, Infisical, and Doppler each track expiry for the tokens and leases inside their own system. A Stripe API key pasted into a Postman collection, or a GitHub PAT with no owner after someone leaves, sits outside that view. That gap is credential sprawl, and it is where lifecycle monitoring adds a metadata-only layer: ownership, expiry dates, and rotation deadlines, without holding the secret value.
Evaluation criteria and where KeyGuardRail falls short
| Criterion | Vault / Infisical / Doppler | KeyGuardRail |
|---|---|---|
| Stores secret values | Yes | No, metadata only |
| Expiry tracking for external SaaS keys (Stripe, GitHub) | Partial, per-system | Yes |
| Ownership and rotation deadlines | Varies | Yes |
| Automated rotation | Vault and Infisical offer some | No, alerts and audit trail only |
| Self-serve signup | Yes | Yes |
The honest read: KeyGuardRail does not replace your vault and cannot rotate anything for you. If you want a single deadline tracker for keys your vault never sees, that is the fit.
FAQ
Why did my Gemini API key stop working overnight?
Gemini keys carry no built-in expiry, so an overnight failure usually means the key was revoked, the underlying Google Cloud project hit quota or billing limits, or Google restricted it for policy reasons. Check that the key still exists in AI Studio and that the project's billing is active, then create a replacement and swap it into your vault.
Is it safe to create a GitHub fine-grained token with no expiration?
You cannot. GitHub requires an expiration date on every fine-grained personal access token; the maximum is a custom date up to one year out. Organization policies can also cap token lifetime or block them entirely, cutting your window shorter. Record the owner, expiry date, and affected resources when you create the token.
Do Salesforce refresh tokens expire if the user never logs out?
Not on a timer by default. They stay valid until revoked, until a policy changes, or until the connected app's configured validity window lapses. The connected app's own policy and the org-level Refresh Token Policy under Session Settings both control that window, so track the issuing app, owner, and policy setting rather than an expiry date.
How do I find which AWS access keys in my account are close to the 90-day mark?
IAM exposes CreateDate per key and LastUsedDate via iam get-access-key-last-used. List keys per user, flag anything older than 90 days, and delete stale keys that show no recent use rather than rotating them. Running this as a scheduled Lambda that posts to Slack with an owner tag keeps someone accountable.