Passbolt maintenance at scale: why large action log purges stall

At a glance

What this is: This is Passbolt’s guidance on safely purging large action_logs tables and reclaiming disk space without destabilising production.

Why it matters: It matters because IAM and NHI platforms often accumulate audit and activity logs that eventually become an availability risk, not just a storage issue.

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.

👉 Read Passbolt's guidance on large action log maintenance and cleanup

Context

Large identity and audit tables are a governance problem once they start affecting availability. In Passbolt’s case, the action_logs table can grow into the millions of rows, and a naive purge can create lock contention, timeouts, and a service that feels frozen during maintenance.

For IAM and NHI teams, the lesson is that retention policy and operational safety are part of the control design. If log cleanup is left until the dataset is huge, the cleanup itself becomes a production event rather than a routine admin task.

Key questions

Q: How should teams clean up large audit or activity logs without causing downtime?

A: Use staged deletions, not a single massive purge. Start with the oldest data, limit each batch, and schedule the work in a maintenance window with a backup in place. That reduces lock time, avoids timeout-prone transactions, and gives operators a safe stopping point if the system begins to slow.

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. At that point, retention is affecting service availability. Teams should monitor table growth and treat volume thresholds as a trigger for planned maintenance, not surprise administration.

Q: What do security teams get wrong about deleting old logs?

A: They often assume delete operations will also free disk space immediately. In many databases, deletion only marks space reusable inside the table. If storage pressure matters, teams need a separate rebuild step and enough capacity to complete it safely.

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.

Technical breakdown

Why large action_logs purges lock production systems

The action_logs table stores security-relevant events such as authentication, secret copy activity, and logout events. When the table reaches hundreds of thousands or millions of rows, a single delete statement can become a large transaction that holds locks for too long, pushes IO hard, and triggers wrapper or cron timeouts. The result is not just slower cleanup. The database can become unresponsive while the transaction completes, especially under limited CPU, IOPS, or table-level contention.

Practical implication: treat high-volume log purges as production maintenance, not as a background job.

Why deletion and space reclamation are different operations

Deleting rows removes data logically, but InnoDB typically keeps the freed pages for reuse inside the table rather than returning space to the operating system. That is why performance may improve after a purge even when disk usage does not fall. Reclaiming filesystem space usually requires a rebuild, such as OPTIMIZE TABLE, which copies the data and can temporarily need disk space close to the table size.

Practical implication: separate purge planning from storage-reclaim planning and do not assume a delete will shrink the database files.

How to reduce purge risk with granular retention steps

Passbolt’s recommended pattern is to purge in several passes, starting with older retention windows and using larger batch limits rather than asking the database to delete everything older than a single threshold in one run. This reduces the odds of one giant transaction and gives administrators a safe stopping point if the maintenance window closes. The control is operational pacing: smaller, staged purges lower the blast radius of cleanup work.

Practical implication: stage purges from oldest data forward and verify each pass before moving to the next threshold.

NHI Mgmt Group analysis

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.

Cleanup windows are part of the control surface, not an admin convenience. Passbolt’s warning about long-running deletes and table rebuilds reflects a broader governance reality: maintenance procedures fail when they assume low-volume behaviour in high-volume systems. Once the table is large enough, the difference between a safe purge and an outage is often the maintenance window itself. Practitioners should align retention policy with operational capacity.

Storage reclamation is a separate lifecycle decision from data deletion. The article distinguishes logical removal from physical space recovery, which is the right mental model for identity telemetry and audit data. Many programmes stop at delete, then discover that capacity pressure remains because the files never shrink. Practitioners should plan for the full lifecycle of log data, including when space must actually be returned.

Granular purging is the named concept that matters here: controlled cleanup avoids catch-up outages. The article’s core pattern is not simply automation, but staged cleanup with decreasing retention thresholds and increasing batch size. That approach avoids one massive catch-up transaction and gives teams a manageable failure boundary. Practitioners should adopt cleanup designs that can fail safely instead of all at once.

From our research:

• 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.
• That is why the Ultimate Guide to NHIs remains the better companion resource for teams designing lifecycle, rotation, and offboarding controls around machine identities.

What this signals

Granular cleanup is now a lifecycle pattern for identity telemetry, not a niche database trick. Teams that manage passwords, service accounts, or vault activity at scale should expect audit data to behave like any other growing identity asset. The operational question is whether retention thresholds, purge cadence, and table maintenance are built into the programme before the logs become a production issue.

The storage signal is straightforward: if you cannot reclaim space safely, then deletion is only half a control. That is why IAM and NHI programmes should coordinate with database teams on backup, rebuild, and capacity planning rather than assuming log retention is a purely security-owned task.

Action log growth is a warning sign that governance and operations are drifting apart. In environments where identity telemetry is valuable for investigations, the control objective is to preserve evidence without letting evidence handling degrade the system that produces it. Practitioners should map this to retention policy, maintenance windows, and platform resilience together, not separately.

For practitioners

• 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.
• Validate service recovery after cleanup Confirm responsiveness, login success, and row-count reduction after each purge before deciding whether another pass or a rebuild is safe.

Key takeaways

• Large action log tables can turn ordinary cleanup into an availability event if teams treat purge jobs as routine administration.
• Deleting rows and reclaiming disk space are different controls, so storage planning must include both the purge and any rebuild step.
• Staged retention passes are the safer pattern because they reduce lock time, lower timeout risk, and let operators stop before the system is overloaded.

Key terms

• Action log retention: Action log retention is the policy and operational practice that determines how long identity and activity events are kept before deletion. In practice, the control must balance audit value, storage pressure, and the risk that cleanup jobs themselves affect system availability.
• Table rebuild: A table rebuild is a database operation that rewrites table contents so storage can be reorganised and, in some cases, disk space can be reclaimed. It is more disruptive than row deletion because it can lock the table, consume temporary space, and extend maintenance windows.
• Maintenance window: A maintenance window is an approved period when production impact is expected and controlled work can be performed. For large identity or audit tables, it is the governance boundary that makes risky cleanup safe enough to execute without surprising users.
• Granular purge: A granular purge is a staged deletion approach that removes old data in smaller passes instead of one large transaction. It reduces lock contention, lowers timeout risk, and gives operators the ability to stop before the cleanup process destabilises the system.

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.

👉 Passbolt's full post covers the purge sequence, rebuild trade-offs, and validation checks in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.