Skip to main content

​
Deleting and restoring

Deleting a secret removes nothing immediately. It moves the secret into a recovery window and returns deleted_at and scheduled_purge_at. Once scheduled_purge_at passes, the secret and every version are removed for good.
Open the secret from Secrets and use Delete secret, in the Danger zone on its Settings tab. The dialog takes a Recovery window (days) and will not confirm until you type the secret’s name back.
​
integer, 1–30, default 7
1 to 30 days, defaulting to 7. Set it at creation to give a secret its own default, or pass it on the delete call to override it for that deletion.
​
timestamp
When deletion was requested. Absent while the secret is active.
​
timestamp
When the secret becomes eligible for permanent destruction.
Secrets allow a 1-day minimum because deletion affects that secret. KMS keeps its 7-day minimum because deleting a key makes every ciphertext and wrapped data key protected by it unreadable. While a secret sits in the window:
  • GET /v1/secrets/{id} still describes it, so you can see the purge date.
  • Reading or writing the value is refused with 409 SECRET_DELETED.
  • Updating metadata is refused the same way.
  • It is hidden from GET /v1/secrets unless you pass include_deleted=true.
Restoring cancels the purge and puts the secret back. Restoring one that was never deleted is a harmless no-op. Unlike cancelling KMS deletion, restoring a secret returns it directly to service; no separate enable action is needed.
A secret in the window shows Restore in its header, in place of Put New Value.
Repeating the delete does not extend the window. A second DELETE during the window keeps the original scheduled_purge_at rather than pushing it out, so a retry loop or a re-run of a teardown script cannot quietly keep a secret alive forever. If you need more time, restore the secret and delete it again with a longer recovery_window_days.
Deleting frees the secret’s quota straight away, so you can create a replacement without waiting out the window. Restoring has to take that quota back, which means a restore can fail with 403 QUOTA_EXCEEDED if your account has since filled the slot. Free one before restoring.