Cadence, history & plans
How often each plan can re-check a credential, how long run history is kept, and which alert channels are available.
Credential validation works the same way on every plan. What changes with the plan is how often you can re-check a credential and how far back its history goes.
How often a credential is re-checked#
Each validated path has a Re-validate every setting. The fastest cadence you can choose depends on your plan:
| Plan | Fastest re-check |
|---|---|
| Solo Professional | every 1 hour |
| Team | every 15 minutes |
| Business | every 5 minutes |
| Enterprise | every 1 minute |
The slowest is 30 days on every plan. A credential that is never re-checked is not being validated, so there is a ceiling as well as a floor.
Every check is a real sign-in to the provider with your credential. That spends your own rate limit with them, and repeated authentication from one place is exactly what their abuse detection watches for. What validation catches — a rotation, an expiry, a revocation — changes over hours and days, not seconds. Most paths are well served by the default for their environment.
The interval you did not set#
Leaving Re-validate every on Environment default picks a cadence from where the path lives: production every 15 minutes, staging and test hourly, development every 6 hours — production gets the tightest cadence because broken production credentials hurt most.
That default is held to your plan's floor too. On Solo Professional a production path inherits hourly rather than 15-minute checking.
If your plan changes#
Cadence is applied continuously, not frozen when you saved the path. Upgrade and your existing paths can be set faster straight away; downgrade and they settle to the slower cadence on their own. You will not find a path silently running at a speed you no longer have.
Checking from CI does not disturb the schedule#
A pipeline that validates a path — through the CLI, the GitHub Action or the GitLab template — runs a check in addition to the scheduled ones. It does not consume them, and it does not push the next scheduled run further out. A path on hourly checking is still checked hourly no matter how often your pipelines ask.
That matters because it keeps the uptime figure honest: uptime is measured from the scheduled runs only, so a busy deploy day cannot flatter it, and a pipeline validating every twenty minutes cannot crowd the scheduled checks out entirely.
Two things keep the cost of that bounded, and neither is something you configure:
- A result from the last 30 seconds is reported rather than re-run. A matrix build fanning twelve jobs at one path produces one sign-in with your provider, not twelve. Writing to the path always forces a real check, so rotating a credential and then validating it never returns the older answer.
- Repeated checks of one path are rate-limited. A runaway pipeline gets a "try again shortly" rather than an open line to your provider's rate limit.
If your pipeline only needs to know a credential was working recently, ask for the recorded result
instead of a new probe — --max-age on the CLI, or max-age in either CI integration. It reads what
your scheduled checks already produced, so it stays inside the cadence you are paying for and sends no
traffic to your provider at all. See CI/CD pipelines.
How long run history is kept#
Every run is recorded — when it started, whether it passed, how long it took, and why it failed. How far back that record goes depends on the plan:
| Plan | Run history kept |
|---|---|
| Solo Professional | 30 days |
| Team | 90 days |
| Business | 180 days |
| Enterprise | 365 days |
Older runs are removed automatically.
A credential's current state — verified, degraded, failing — comes from the credential itself, not from how much history happens to be kept. Shorter retention means a shorter chart, never a less accurate badge.
Alerting#
Alerting itself is not plan-gated: every plan that can validate a credential can be told when one breaks, through email, Slack or a webhook. See Alerts & routing.