What is a key overlap window?

A key overlap window is the period during which a provider accepts both the old and the new version of a credential, so that you can roll the new value out to every service before the old one is revoked, and nothing fails in between.

Why it exists

Replacing a credential that live systems use has a timing problem. Revoke the old value first, and every service still using it fails until it gets the new one. Deploy the new value first, and you need the provider to accept it while the old one is still in use. The overlap window is how providers solve this:

• AWS allows two access keys per IAM user. Its procedure is to create the second key "while the first access key is still active", update every application, check the old key's last use, deactivate it, and delete it later (AWS).
• Stripe builds it in: when you rotate a key in the Dashboard, "both the old and new keys work for up to 7 days". If you need longer, Stripe suggests creating a new key manually and expiring the old one when the migration is done (Stripe).

Some frameworks offer the same for signing secrets. Django's SECRET_KEY_FALLBACKS, for example, holds previous keys so that a new SECRET_KEY doesn't invalidate existing sessions and password reset tokens at once (Django).

How a reissue uses it

1. Create the new credential while the old one still works.
2. Deliver the new value to every consumer.
3. Watch the old credential's usage drop to zero, using the provider's last-used date or request logs.
4. Revoke the old credential.

The window is a convenience for planned work. After a leak, it is also a risk: as long as the old value works, so does the copy someone else has. Keep the window as short as your rollout allows.

Common mistakes

• Letting the window run out on its own. If a key expires automatically after seven days, a service you forgot fails on day eight, at a time you didn't choose. Find the stragglers from the logs and revoke on purpose.
• Assuming every credential has one. Many don't. A token that is revoked the moment a new one is issued needs a short planned switch instead.
• A long window after a compromise. For a leaked value, overlap only as long as the deployment takes.

How Crunu helps with step 2

Crunu doesn't create or revoke credentials at providers, so it doesn't control the window. It shortens step 2, the part that usually makes windows long. Save the new value as a new version of the environment, and every service started with crunu run --restart on-change restarts with it, without a redeploy:

crunu run --env payments-api/production --restart on-change -- /opt/payments/bin/server

crunu waits for changes to settle for 2 seconds, sends SIGTERM, waits up to --stop-timeout (30 seconds by default) and starts the program again with the new variables. Only the names of changed variables are logged. Pipelines that read the environment with a service token get the new value on their next run.

Whether a given provider supports overlap is listed for each service in the rotation guides, for example Stripe. Where the window fits into a departure is covered in what to rotate when a developer leaves, and the rollout pattern in more depth in rotating API keys without downtime.

Sources

• AWS IAM: Update access keys, checked October 30, 2026.
• Stripe Docs: API keys, checked October 30, 2026.
• Django 6.1 settings: SECRET_KEY_FALLBACKS, checked October 30, 2026.