hashicorp · kpcraig · Sep 9, 2025 · Sep 2, 2025 · Sep 8, 2025 · Sep 8, 2025
@@ -184,6 +184,8 @@ Use `vault path-help` for more details.
 The root bindpass can be rotated to a Vault-generated value that is not accessible by the operator.
 This will ensure that only Vault is able to access the "root" user that Vault uses to manipulate credentials.
 
+Vault logs manual root rotations to `vault.log` with a note that the rotation was `on user request`.
+
 ```shell-session
 vault write -f auth/ldap/config/rotate-root
 ```
@@ -231,6 +233,8 @@ TTL.
 For more details on rotating root credentials in the Azure plugin, refer to the
 [Root credential rotation](/vault/api-docs/auth/ldap#rotate-root) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Examples:
 
 ### Scenario 1

@@ -104,7 +104,7 @@ TTL.
 For more details on rotating root credentials in the DB Secrets engine, refer to the
 [Rotate Root credentials](/vault/api-docs/secret/databases#rotate-root-credentials) API docs.
 
-
+@include 'rotation-manager-logging.mdx'
 
 ## Setup
 
@@ -296,6 +296,8 @@ or otherwise, it will not be rotated until the next scheduled rotation.
 !> The `rotation_period` and `rotation_schedule` fields are
 mutually exclusive. One of them must be set but not both.
 
+Vault logs rotations with reference to the `name` of the role and `error` if the rotation failed. The logs also indicate if the rotation was part of a `periodic function`.
+
 ## Password generation
 
 Passwords are generated via [Password Policies](/vault/docs/concepts/password-policies).

@@ -158,6 +158,8 @@ TTL.
 For more details on rotating root credentials in the Azure plugin, refer to the
 [Root credential rotation](/vault/api-docs/secret/ldap#rotate-root) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Static credentials
 
 ### Setup
@@ -194,11 +196,17 @@ role, the response will include the time before the next rotation (`ttl`).
 The `binddn` account used by Vault should be rotated using the `rotate-root` endpoint to generate a password
 only Vault will know.
 
+As with the rotation manager, Vault logs rotations with reference to the
+`name` of the role and `error` if the rotation failed. The logs also indicate
+ if the rotation was part of a `periodic function`.
+
 ### Manual rotation
 
 Static roles can be manually rotated using the `rotate-role` endpoint. When manually
 rotated the rotation period will start over.
 
+Logging for manual rotation records the same information as other rotation logging with an additional reference that the rotation happened `on user request`.
+
 ### Deleting static roles
 
 Passwords are not rotated upon deletion of a static role. The password should be manually

@@ -0,0 +1,12 @@
+### Rotation logging
+
+The rotation manager emits logs to the standard `vault.log` on any successful or
+failed rotation.
+
+In the case of success, Vault notes:
+
+- the rotated credential as the first parameter, `rotationID`.
+- the anticipated time of the next rotation as `expire_time`.
+
+In the case of failure, Vault sets `rotationID` to `err` and may emit additional
+logs depending on the configured log level.
@@ -198,6 +198,8 @@ This will ensure that only Vault is able to access the "root" user that Vault us
 vault write -f auth/ldap/config/rotate-root
 ```
 
+Vault logs manual root rotations to `vault.log` with a note that the rotation was `on user request`.
+
 ### Schedule-based root credential rotation
 
 @include 'alerts/enterprise-only.mdx'
@@ -241,6 +243,8 @@ TTL.
 For more details on rotating root credentials in the Azure plugin, refer to the
 [Root credential rotation](/vault/api-docs/auth/ldap#rotate-root) API docs.
 
+@include rotation-manager-logging.mdx
+
 ## Examples:
 
 ### Scenario 1

@@ -105,6 +105,8 @@ TTL.
 For more details on rotating root credentials in the DB Secrets engine, refer to the
 [Rotate Root credentials](/vault/api-docs/secret/databases#rotate-root-credentials) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Setup
 
 Most secrets engines must be configured in advance before they can perform their
@@ -397,6 +399,8 @@ or otherwise, it will not be rotated until the next scheduled rotation.
 !> The `rotation_period` and `rotation_schedule` fields are
 mutually exclusive. One of them must be set but not both.
 
+Vault logs rotations with reference to the `name` of the role and `error` if the rotation failed. The logs also indicate if the rotation was part of a `periodic function`.
+
 ## Password generation
 
 Passwords are generated via [Password Policies](/vault/docs/concepts/password-policies).

@@ -155,9 +155,11 @@ of the root credential until the field is reset to `false`. If you use
 `rotation_period`, setting `disable_automated_rotation` also resets the credential
 TTL.
 
-For more details on rotating root credentials in the Azure plugin, refer to the
+For more details on rotating root credentials in the LDAP plugin, refer to the
 [Root credential rotation](/vault/api-docs/secret/ldap#rotate-root) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Static credentials
 
 ### Setup
@@ -194,11 +196,17 @@ role, the response will include the time before the next rotation (`ttl`).
 The `binddn` account used by Vault should be rotated using the `rotate-root` endpoint to generate a password
 only Vault will know.
 
+As with the rotation manager, Vault logs rotations with reference to the
+`name` of the role and `error` if the rotation failed. The logs also indicate
+ if the rotation was part of a `periodic function`.
+
 ### Manual rotation
 
 Static roles can be manually rotated using the `rotate-role` endpoint. When manually
 rotated the rotation period will start over.
 
+Logging for manual rotation records the same information as other rotation logging with an additional reference that the rotation happened `on user request`.
+
 ### Deleting static roles
 
 Passwords are not rotated upon deletion of a static role. The password should be manually

@@ -0,0 +1,12 @@
+### Rotation logging
+
+The rotation manager emits logs to the standard `vault.log` on any successful or
+failed rotation.
+
+In the case of success, Vault notes:
+
+- the rotated credential as the first parameter, `rotationID`.
+- the anticipated time of the next rotation as `expire_time`.
+
+In the case of failure, Vault sets `rotationID` to `err` and may emit additional
+logs depending on the configured log level.