History, deletion trace & recovery

Every change to a secret is recorded, every deletion is recoverable for a window, and any path can be compared between two points in time. This page covers the three screens that expose that.

Who changed what — the Activity page#

Projects → your project → Activity.

One feed of every change and deletion in a namespace, by people and by machine identities together. That combination is the point: "who deleted this?" does not care whether the answer is a colleague or a CI pipeline, and until you can see both in one place the answer is always "check somewhere else too".

Each row names the actor, the action, and the full path it touched. Machine rows are marked and can be filtered out; so can human ones.

Above the feed, secrets that have not been rewritten in 90 days are listed. Age alone is a weak signal — a value that never needs to change is not a problem — but paired with a credential's validation status it becomes actionable: still working is a different decision from failing.

Getting a deleted secret back — the Recycle bin#

It lists what was deleted under the path you are on, exactly like the Keys and History tabs beside it — the folder itself and everything below it, never a sibling that merely shares a prefix. Open it at the namespace root to see every deletion in the namespace; the panel says which of the two you are looking at, and says so on an empty list too, where "nothing deleted" would otherwise read as a claim about the whole namespace.

Restoring asks first. It is not destructive, but it is a one-click change in a list of near-identical rows, and it puts a credential someone deliberately deleted back in front of every CI job that reads that path. The confirmation names the key, how many versions come back with it, who deleted it, and that any validation parked while it was gone is re-armed.

A tab in the secrets browser, beside Keys. Recovery lives where deletion happens.

Deleting a secret stops it answering reads immediately — CI gets a 404 — but destroys nothing. It moves here, keeping its full version history, and Restore brings it back for 30 days. The bin shows who deleted each one and the date its window closes.

After 30 days a nightly job removes it and the values are gone for good. A restore attempted past the window fails and says so, rather than reporting "not found": the secret did exist, and pretending otherwise would send you looking for a typo.

Comparing a path across time — the History tab#

A tab in the secrets browser, beside Keys and Recycle bin — on paths that hold keys.

A path is either a folder of sub-paths or a holder of keys, never both. On a folder the browser is a listing, so the tabs are not shown there: "History" would offer the timeline of a place that stores nothing, next to a "Keys" tab labelling a list of folders. Navigate into a path that holds keys and the tabs appear.

The Recycle bin still has its own button beside the breadcrumb where the tabs are hidden: deleting the last key under a path turns that path back into a folder, and the bin must not become unreachable from exactly the place you just deleted something.

The timeline lists what happened at the path you are looking at: which key each entry concerns, its version number, who wrote it, its size, and any descriptors recorded at the time. Removals appear in the same list, in order — a delete is a thing that happened, and splitting it into a separate view would make the sequence impossible to read.

Whatever you are looking at is the scope — the path in the breadcrumb, and nothing above it. A path holding several keys shows all of them in one timeline, which is usually what you want: one place to see what has been happening under db/postgres/db1 rather than a key at a time.

Seeing what a version contained#

View value on any version reveals that version's plaintext. It is the same step-up and the same audit entry as revealing from the Keys tab — history is where the question "what was it before?" gets asked, so the answer belongs here rather than on another screen.

The value stays on screen until you hide it, and it is in your scrollback afterwards. Reveals are audited individually.

This works for deleted secrets too, right up until they are purged. A soft-deleted secret sits in the Recycle bin with its versions intact, and "what was in the thing I deleted?" is exactly the question you ask before deciding whether to restore it. The permission is unchanged — you still need reveal on the namespace — and refusing would buy nothing anyway, since you could restore it, read it, and delete it again.

Writing to a deleted secret is still refused. Restoring it stays a deliberate act rather than a side effect of an edit.

Comparing two moments#

Three ways to set the range, and the third is the one worth knowing:

1. A quick range — Last 24 hours / 7 days / 30 days / All history. One click.
2. The two pickers, for anything the presets cannot express.
3. The timeline itself. Hover any row and it offers From here / To here. Because our versioned unit is the key, there is no "version 5 of this folder" to select — the comparison points are the instants something under the path actually changed, and those are exactly the rows listed below. The list is the picker.

Above the button, the panel says how many recorded changes the current range covers, so you learn a range spans nothing before spending a comparison on it rather than after.

Both ends are inclusive of the minute you choose. From is read as :00 of that minute and To as :59, so picking the same minute at both ends still spans it rather than spanning nothing.

The times are shown and entered in your timezone — the one set on the Preferences page, or your browser's if you have not set one. The panel says which, under the pickers. Every timestamp in the timeline below is in the same zone, so a moment you read off a row can be typed straight into a picker.

Minutes matter here more than they look like they should. A rotation, the deploy that broke on it and the fix ten minutes later are all the same calendar day, and that afternoon is the one people open this panel for.

Why there is no "version 5" of a folder#

A single secret has version numbers. A path does not, and that is deliberate: versions belong to keys here, not to folders. Two systems writing different keys under the same path never overwrite each other, rotating one credential does not bump five unrelated ones, and a per-key read grant means something.

The cost is that there is no folder-wide counter to select. So the comparison points are the moments something under the path actually changed — which is what a folder version number would have been for anyway.

The comparison itself never shows values#

It reports which keys were added, rewritten or removed, with the version numbers on each side. It does not show what any value became. Reading a value stays a deliberate, separately audited act on one key at a time — a whole-path comparison that printed plaintext would put every credential under a folder on screen at once.

Two things worth knowing about the result:

• "Changed" means a new version was written between the two points, not that the value is different. Writing the same bytes twice still counts, because proving otherwise would mean decrypting both.
• The sizes on each side are a safe hint at whether the content really moved.

Where the history stops, and why#

If earlier history is not available the panel says so, and says which of two reasons applies:

• Versions were removed by the retention cap. Your plan keeps a fixed number of versions per secret, not a fixed age, so a frequently-written key has a shorter reachable history than a quiet one.
• Paths before a date were inferred. Version history gained its own record of where each version was written; anything older had that filled in from where the secret sits now. Correct unless the secret was renamed — and entries in that range are badged.

This is deliberate. A history view that showed a partial past as if it were complete would be worse than one that admits the gap, because you would draw conclusions from an absence that was never real.

Putting a whole path back#

From a comparison you can restore the path to how it stood at the earlier moment. It is atomic — all of it applies or none does — and append-only for values: restoring writes new versions rather than rewinding, so the history keeps showing that the newer values existed and were replaced.

Review it first — the comparison is not the operation#

Pressing Restore this path to … does not restore anything. It opens a review listing what the restore would do, key by key, worked out by the server:

This is a different list from the comparison above it, and that is the point. A comparison says what changed between two moments; a restore performs what it takes to get back to the earlier one. A key created since shows as added in the comparison but is a removal here. A key at the same version at both ends needs no write at all. Working that mapping out in your head is not something the screen should ask of you before it writes to a production path.

Every row is a checkbox, and the ticked rows are the operation — untick anything you want left alone. Nothing is authorised until you confirm, and the step-up prompt comes after the review, not before it.

Removing keys created since#

Reaching an earlier state can require deleting keys that did not exist then, so those rows are offered — and they are the only destructive thing here.

Two guarantees. The delete is soft: the key goes to the Recycle bin with the usual 30-day window, and it is tombstoned and audited like any other deletion. And it is opt-in per key: the API removes a key only when that exact path is named, so no bulk "restore this folder" can delete anything, from the console or anywhere else.

Refused if anything moved#

If a key changed after the review was generated, the restore is refused and asks you to compare again. Confirming a five-minute-old review would otherwise silently discard whatever was written in those five minutes. The check covers every key the restore would act on — rewrites and removals alike — not only the ones the comparison highlighted, so a key that looked unchanged when you read it and was then edited by a colleague stops the restore rather than being overwritten.

Afterwards#

The result names each key with the version it is now at and the version that value came from, and each key removed with its recovery deadline. On the timeline the new versions carry a restored from vN badge — without it a restore is indistinguishable from someone re-typing the old value by hand, since it has the same author, the same size and the same everything else.

A restore that would write nothing is refused rather than reported as a success. That case is more common than it sounds: it is every comparison whose only changes are keys created since the earlier moment, where the answer is "there is nothing to put back — only things to remove".

From the CLI#

pulsvault path-diff acme-web/prod/product/web/db --from 2026-08-01T00:00:00

Same comparison, same rules — structural only, and it needs list on the path rather than read. See Versions & rotation.

Related#

• Browsing secrets & folders
• Secrets & versioning
• Versions & rotation (CLI)