The page comes in at 3:11am: order sync to the fulfillment provider has stopped. No deploy went out, nothing changed, and every server is healthy. Forty minutes of bleary log-reading later, the on-call engineer finds it: the service account credential the integration used expired at midnight. Nobody set a reminder. Nobody knew it had an expiry date. And now a queue of unshipped orders is backing up while a customer-facing SLA quietly burns. This is the anatomy of a service account expiration incident, and it is one of the most common, most preventable outages in modern SaaS.
The maddening part is that this failure is entirely knowable in advance. An expiry date is a fact you have. You just have to be watching it. This post is about how to watch it at scale, so the 3am page becomes a calm reminder weeks earlier.
What service accounts are and why they expire
A service account is a non-human identity (an account, key, token, or certificate) that one system uses to authenticate to another. The nightly job that pushes orders to a fulfillment API, the integration that reads from a partner's system, the credential your monitoring uses to log into a database: all service accounts. Modern products have dozens or hundreds of them.
And most of them expire by design. API keys are rotated on a schedule, OAuth client secrets have validity windows, TLS client certificates have not-after dates, and cloud provider keys are increasingly issued with mandatory expiry. Expiration is good security hygiene, and a credential that lives forever is a liability. But every expiry date is also a scheduled outage waiting to happen if nobody is tracking it.
The real-world impact of an expired service account
When a service account expires unnoticed, the failure mode is uniquely nasty because it is silent and total for one integration while everything around it looks fine:
- Integration failures. The specific data flow that depended on the credential simply stops. Orders don't sync, webhooks don't deliver, reports don't generate.
- Monitoring blind spots. Worse still, if the expired credential was used by your monitoring, you lose visibility into the exact thing you needed to watch. The check goes to
unknown, and if you treat unknown as green, you are now blind and unaware. - Production incidents at the worst time. Expiries don't respect business hours. A credential set to expire ninety days ago lands on a random Tuesday at midnight, or over a holiday weekend.
- Slow, painful diagnosis. Because nothing "changed" and infrastructure is healthy, these incidents take far longer to diagnose than a normal outage. The cause is invisible unless you think to check credential validity.
The silent-monitoring trap: the single worst version of this is an expired credential inside a health check itself. Your dashboard shows green, because the check that would have caught the problem can no longer run. Always treat a check that returns "unknown" as a real problem, never as healthy. See defining service health status for why the unknown state matters.
Why service account expiration is so hard to track at scale
If it is so knowable, why does it keep happening? Because tracking expiry across a real estate is genuinely hard:
- Credentials are scattered. They live in different secret managers, provider dashboards, config files, and someone's terminal history. There is rarely one place that lists them all.
- Expiry dates are inconsistent. Some are in the credential metadata, some only in a provider console, some nowhere machine-readable at all.
- Ownership is fuzzy. The engineer who created a service account two years ago has left. Nobody remembers it exists until it fails.
- The count grows silently. Every new integration adds credentials. What was manageable at ten is unmanageable at two hundred, and the growth is invisible until an incident.
This is a product health problem, specifically the security dimension of it. A valid, non-expiring credential is part of what "healthy" means for any integration, which is why it belongs in your monitoring rather than in someone's memory. For the broader framing, see what is product health monitoring.
Best practices for tracking service account expiration
A workable practice has two parts: know what you have, and get warned in time.
1. Maintain a live inventory
You cannot monitor what you have not enumerated. Build and maintain an inventory of every service account: what it is, what integration uses it, who owns it, and, critically, when it expires. The inventory has to be living, not a one-time audit, because new credentials appear constantly.
2. Alert on a staged schedule
A single alert "it expired" is useless, because it fires at the moment of the outage. Instead, alert on a staircase of lead times so there is always room to act:
- 90 days out: plan the rotation into a sprint.
- 30 days out: it should be scheduled work now.
- 7 days out: escalate, this is becoming urgent.
- 1 day out: page-worthy. Something has gone wrong with the plan.
The staged windows turn a cliff into a ramp. And alerts should go to multiple recipients, the owner plus a team address, because the whole problem is that the single owner may have left or be on vacation.
3. Auto-disable on expiry
When a credential does lapse, the integration that uses it should fail safe and visibly rather than retry-storm against an endpoint with a dead key. Marking an expired credential as disabled, loudly, is better than letting it hammer a provider and get you rate-limited on top of the outage.
4. Make rotation routine, not heroic
Staged alerts only help if rotating a credential is a well-worn path rather than an emergency. When the 90-day warning fires, the owner should know exactly how to rotate that credential: where it lives, what depends on it, and how to swap it without downtime. Document the rotation procedure alongside the inventory entry, so the person who acts on the alert is not also reverse-engineering how the integration authenticates. The combination that works is early warning plus a rehearsed response: the alert tells you when, and the runbook tells you how. Teams that get paged at 3am for expiries almost always have one without the other.
Why the spreadsheet always fails
Most teams' first instinct is a shared spreadsheet of credentials and expiry dates. It works for exactly as long as one diligent person maintains it, and then it rots. Someone adds an integration and forgets to log it. A date is entered wrong. Nobody sets the reminders. The spreadsheet becomes a document that describes the credentials you remembered to write down six months ago, which is precisely not the set that will surprise you.
A manual credential inventory is a promise to remember something boring, forever, perfectly. That is not a promise software should ever ask a human to make.
The failure is structural, not a discipline problem. Expiry tracking is a job for a system that watches automatically and nags on a schedule, because the entire value is in catching the thing everyone forgot.
How Sentrock tracks credential expiration automatically
Sentrock treats credential expiration as a first-class part of product health. When you connect a product with managed credentials, Sentrock captures the expiration date and watches it as part of the credential management feature. As the date approaches, it sends advance reminders on a staged schedule (90, 30, 7, and 1 days out) to multiple recipients, so a warning never depends on one person seeing it. Expiring credentials are flagged on the dashboard well before they lapse, and anything that does expire is automatically disabled so it fails safe instead of silently breaking a check. The result is that "a credential expired and took down an integration" moves from a recurring 3am incident to a routine, well-signposted piece of planned maintenance.
Takeaways
- Every service account with an expiry date is a scheduled outage unless something is watching it.
- The impact is uniquely bad: silent, total for one integration, slow to diagnose, and sometimes blinding your monitoring itself.
- Track it with a living inventory plus staged alerts at 90/30/7/1 days, sent to multiple recipients.
- Do not rely on a spreadsheet; the whole point is catching what everyone forgot, which is exactly what manual tracking misses.
Expiry is one of the rare outages you can see coming with certainty, if you are watching. To fit it into a complete practice, read SaaS reliability monitoring best practices, or start tracking your credentials so the next expiry is a calendar reminder instead of a page.
Written by the Sentrock Team
Sentrock is a product health monitoring platform for SaaS teams. Define health rules across availability, performance, security, configuration, and compliance. Know the moment something degrades, before your customers do.
Start monitoring your products →