Notifications
Clear all
Topic starter
08/07/2026 6:57 pm
TL;DR: Routine cleanup of large action_logs tables can turn into long-running, lock-heavy maintenance that makes instances slow or unusable, according to Passbolt. The operational lesson is that log retention, purge granularity, and maintenance windows must be treated as production controls, not housekeeping.
NHIMG editorial — based on content published by Passbolt: Automating Passbolt Maintenance, Part 2: Prepare the first run on large databases
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: How should teams clean up large audit or activity logs without causing downtime?
A: Use staged deletions, not a single massive purge.
Q: When does log retention become an operational risk instead of a harmless archive?
A: It becomes a risk when the cleanup job itself can lock tables, saturate IO, or push the system into timeout territory.
Q: What do security teams get wrong about deleting old logs?
A: They often assume delete operations will also free disk space immediately.
Practitioner guidance
- Classify log cleanup as a maintenance change Schedule purge activity like any other production-impacting change, with a communicated window, a verified backup, and a rollback plan before touching large tables.
- Purge in staged retention passes Run smaller, ordered deletions from older data toward newer data so the database never has to process one giant catch-up transaction.
- Separate deletion from space reclamation Only run OPTIMIZE TABLE when you actually need disk back, because the rebuild can lock the table and require substantial temporary free space.
What's in the full article
Passbolt's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step purge sequencing for very large action_logs tables.
- The exact maintenance considerations for running OPTIMIZE TABLE safely.
- Operational notes on how long a rebuild can lock the database.
- Practical examples of choosing retention thresholds based on instance age.
👉 Read Passbolt's guidance on large action log maintenance and cleanup →
Large action log purges in Passbolt: what breaks first?
Explore further
08/07/2026 7:20 pm
Log maintenance becomes an availability control once audit tables reach scale. The article shows that action logging, while necessary for traceability, can become a self-inflicted denial-of-service condition when retention is unmanaged. In NHI and IAM programmes, the issue is not whether logs are useful, but whether the retention model is still compatible with production operations. Practitioners should treat log volume as an availability input, not just an evidence archive.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Another finding from the same research shows that 97% of NHIs carry excessive privileges, which broadens the blast radius when operational hygiene slips.
A question worth separating out:
Q: Who should own the decision to rebuild a large logs table?
A: Ownership should sit with the team accountable for production availability, usually together with database administration and the security function that depends on the logs. A rebuild changes service behaviour, storage requirements, and recovery risk, so it should not be treated as a routine housekeeping task.
👉 Read our full editorial: Passbolt maintenance at scale: why large action log purges stall
