Credential validation overview
Continuous testing of stored credentials — the primary differentiator. How validation works, the status badges, and configuring a path.
Credential validation continuously tests your stored secrets to verify they still work. A static secret store is a commodity — every competitor has CRUD, RBAC, and audit. None of them tell you whether the stored credential still authenticates. PulsVault does.
The claim: a stored secret is known-working at all times. That claim is only useful if it's true on day one — so validation ships alongside the secret store, not as a future promise.
What gets validated: a path#
Validation attaches to a path, not to one key — because a credential is usually several keys
together. wrk/local/production/web/postgres holds host, port, dbname, username and
password, and none of them alone is "the credential". Attach a probe to the path and it reads the
keys beneath it.
A path holding a single key — an API token, a GitHub PAT — works the same way: the probe reads that one key.
Validation is opt-in. Nothing is validated until you attach a probe to a path, so you decide which credentials are worth watching.
What happens on a schedule#
Once a path is validated, PulsVault re-checks it on the cadence you choose. Each check runs the configured probe — connecting to the database, or calling the API the token belongs to — and records the outcome in the path's validation history: success, failure, timeout, or an error meaning the check itself could not be completed.
Repeated genuine failures raise an alert.
Writing a secret also re-checks its path straight away, so a rotation is known working — or known broken — without waiting for the next scheduled run.
You can also ask for a check at any moment: Run now in the console, or pulsvault validate from a
pipeline. History records which of the three it was, so a run that landed in the middle of a deploy is
recognisable as one. See CI/CD pipelines for gating a deploy on the
answer.
A probe uses the credential to authenticate and nothing else. Values never appear in validation history, in an alert, in a notification, or in any error message — a failure tells you that it failed and why, never with what.
Status badges#
Every validated path shows a badge, both on the path itself and in its parent's listing:
| Badge | Meaning |
|---|---|
| ✓ verified | validated successfully within its interval |
| ⚠ degraded | failing, counting toward the alert threshold |
| ✗ failing | alert firing |
| — disabled | a person turned validation off for this path |
| ⚠ no keys | turned off automatically — the path holds no readable keys. It switches back on by itself the moment a key is written back, so there is nothing to re-enable by hand |
| ? pending | configured but not yet run |
Configuring a path#
Open the path and click Validate this path. Choose a probe; the form then shows that probe's own
fields, with each credential input pointed at a key under the path. Most bind themselves — a key
called password is found automatically — and you only pick from the dropdown when your naming
differs.
The configuration is tested as you edit it, so you can see it working before you save. Validate now re-runs it on demand, and recent runs are listed inline. Remove detaches validation from the path entirely.
- Re-validate every — how often to re-check. Leave it on Environment default and it follows where the path lives: production every 15 minutes, staging and test hourly, development every 6 hours. The fastest cadence available depends on your plan — see Cadence, history & plans.
- Failure threshold — consecutive failures before an alert fires (default 2, up to 100). Single failures are noise; two in a row is a signal. The form shows how long the credential would be failing before you are told, because that depends on the interval beside it.
- Alert route — where a failure is delivered. Leave it unset to use the space default.
- Test-only — keep validating and recording history, but never alert. Useful while you are still tuning a check.
History & retention#
Every run is recorded — when it started, whether it passed, how long it took, and why it failed. A path's drawer in the Validation cockpit shows that record three ways: an Overview with uptime, latency and a breakdown of failure reasons, a History tab listing every individual run, filterable by result, trigger and date, and an Export tab that hands you the same records as a CSV file.
Reading the run chart#
The Overview's run chart always covers the whole window you selected — 24 hours, 7 days, 30 days or 90. How much each bar represents depends on how much history that window holds, and the chart says which above it:
1 bar = 1 run— few enough runs to draw individually. Each bar is one validation.1 bar = 15 h(or whatever the window works out to) — the window is split into equal slices and each bar summarises its slice. Hovering gives the counts: how many runs, how many passed, the most common failure reason, and the average latency.
A bar is green when everything in it passed, amber when some of it failed, and red when all of it did — a distinction a one-bar-per-run chart cannot draw. A grey bar is a slice with no runs in it at all, which is worth seeing: it usually means validation was disabled, or the scheduler did not reach this path.
When the chart is summarising, clicking a bar opens the History tab filtered to that slice, so a spike is something you can look into rather than only notice.
Exporting#
The Export tab produces a CSV of the runs matching a date range, a result and a trigger. One row per run, with its start and end time, result, error category and message, trigger, latency, probe, path and the number of keys it read.
Two limits apply, and the tab tells you before you export rather than quietly giving you less than you asked for:
- One export covers at most 90 days. For a longer period, export it in consecutive ranges.
- The range must fall inside your plan's retention. Nothing is stored before that, so the date picker will not go further back.
The 90-day limit is on the length of the range, not on how recent it is — on a plan that retains 180 or 365 days you can export any 90-day window inside it, not only the most recent one.
How far back the run-by-run history goes depends on your plan — 30 days on Solo Professional up to 365 on Enterprise. See Cadence, history & plans for the full table.
A credential's current health — verified, degraded, failing — is never affected by retention: it is derived from the credential itself, not from how much history happens to be kept.