Unit 13 — Documentation Caveats
Two points where HashiCorp’s own guidance is inconsistent across pages. Both are worth knowing before you build on them.
Dynamic Secrets Management says: start with a generous TTL value (24-48 hrs) and fine-tune based on the application requirements and lifecycle.
Monitoring and Observability says: by selecting the shortest possible TTL for your use case you can prevent a large number of leases expiring at the same time and space out those writes to ease the load on Vault storage.
These reconcile as the shortest TTL that still comfortably exceeds the workload’s actual lifetime — but the two pages emphasize opposite failure modes, and neither states the reconciliation explicitly. In practice: start generous, measure real workload lifetimes, then tighten.
Performance Replication Operations names them vault.wal_persistwals and vault.wal_flushready, with no thresholds.
Monitoring and Observability names them vault.wal.persistWALs and vault.wal.flushReady, with thresholds of >1000 ms and >500 ms.
Confirm which spelling the telemetry actually emits against the Vault telemetry reference before building dashboards.