Passbolt maintenance at scale: why large action log purges stall

At a glance

What this is: PassBolt explains that large action log cleanup on big databases can stall into a long, locking purge that degrades responsiveness and may make an instance unusable until it completes.

Why it matters: For IAM and NHI practitioners, this shows that audit-log retention and cleanup are production controls, because overly aggressive housekeeping can interrupt access to the system itself.

Context

Large audit-log tables can turn routine maintenance into an operational risk when delete volume, table size, and storage behaviour collide. In Passbolt's case, the action_logs table can grow to hundreds of thousands or millions of rows, so a purge is no longer just cleanup; it becomes a production change that can block users and degrade service.

The issue sits at the intersection of identity governance and database operations. Action logs are needed for forensic visibility, but retention choices also determine whether cleanup can be executed safely, whether disk can be reclaimed, and whether the maintenance process needs a window with expected downtime.

Key questions

Q: What breaks when a large action log purge runs without a maintenance window?

A: The purge can hold locks long enough to make the instance slow or unusable, and users may experience delayed logins, stalled queries, or a frozen administration workflow. The risk rises sharply when the delete spans millions of rows, because the operation becomes a production event rather than routine cleanup.

Q: When should teams prioritize log retention changes over disk reclamation?

A: Prioritise row deletion first when the immediate problem is performance or table bloat, and treat disk reclamation as a separate step only when storage pressure remains after the purge. That sequencing avoids turning a cleanup task into a rebuild unless the filesystem footprint is truly the limiting factor.

Q: How do you know a purge strategy is too aggressive for the environment?

A: If dry-run estimates suggest a very large deletion, or if the table has grown across years without maintenance, the strategy is too aggressive for one pass. Indicators include long lock times, wrapper timeouts, and a sharp drop in responsiveness during test runs.

Q: What should administrators do before rebuilding a large action_logs table?

A: Confirm that the maintenance window is reliable, because a rebuild can lock the table and temporarily require significant extra disk space. If the window is not dependable, defer the rebuild and focus on reducing the log volume safely first.

Technical breakdown

Why large deletes turn into lock-heavy maintenance

When a delete spans a large fraction of a table, the database may hold locks for long periods, consume significant I/O, and keep transactions open long enough for timeouts to stack up. That is especially visible on action_logs because every login, secret copy, and logout is recorded, so the table keeps growing even when the system is otherwise healthy. The danger is not only deletion volume but the combination of row count, storage engine behaviour, and execution wrapper limits such as cron or systemd ceilings.

Practical implication: treat large log purges as scheduled change windows, not background maintenance.

Why deleting rows does not always reclaim disk space

Deleting rows removes data logically, but it does not necessarily return storage to the operating system. InnoDB commonly keeps freed pages available for reuse inside the table, which means the table can still occupy the same files even after the row count drops. Reclaiming space usually requires a rebuild operation such as OPTIMIZE TABLE, which is fundamentally different from a purge and can be far more disruptive.

Practical implication: separate purge planning from space-reclamation planning and assume the latter may require more downtime.

Why progressive retention steps are safer than one giant purge

A staggered purge sequence reduces the risk of one massive transaction by attacking the oldest and largest retention buckets first, then stepping forward toward the target window. That approach shrinks the biggest accumulation early, leaves room to stop if the maintenance window closes, and avoids asking the database to delete everything older than one threshold in a single pass. On very old instances, the starting retention point should match how long the server has actually existed and how much unmaintained history exists.

Practical implication: purge from the oldest retention bucket downward instead of running one catch-all delete.

NHI Mgmt Group analysis

Large audit-log cleanup is a production control, not a housekeeping task. The article shows that once an action log reaches the million-row range, maintenance behaviour changes from routine admin work into a service-availability decision. That shifts the governance question from whether logs should be retained to how retention can be reduced without breaking the system. Practitioners should treat log cleanup as an availability-sensitive control surface.

Storage reclamation is a separate governance problem from log deletion. The article makes a clear distinction between removing rows and reclaiming disk space, which many teams blur in practice. If the filesystem footprint matters, table rebuilds introduce their own lock and capacity risks, so the operational model has to account for two different outcomes. The implication is that capacity, retention, and maintenance scheduling are linked controls, not isolated tasks.

Progressive purge design is the safest control pattern for oversized operational logs. Starting with older retention windows and stepping forward limits the blast radius of a single transaction and preserves a clean exit if the window closes. That pattern is more durable than one giant catch-up purge because it recognises how quickly the control changes once the dataset becomes large. The practitioner lesson is to design maintenance flows around bounded work units.

Identity audit retention debt: large systems eventually accumulate more evidence than they can safely process in one maintenance cycle. This is not a log-management nuisance but a governance debt that turns audit usefulness into operational fragility when cleanup is deferred too long. Teams should treat the age and volume of identity activity records as a lifecycle issue that must be governed before the table becomes critical.

Maintenance windows are part of the access model for the platform itself. When a purge or rebuild can make the instance unusable, operational access to the system depends on planned unavailability, backup readiness, and user communication. That makes the maintenance window an identity-adjacent control, because it governs when the service may temporarily stop serving authenticated users. Practitioners should align maintenance timing with business tolerance, not with convenience.

What this signals

Identity audit retention debt: when operational logs accumulate faster than maintenance cycles can safely process them, the control problem shifts from retention policy to service resilience. Teams need to model how much evidence they can keep without turning cleanup into an outage event.

The more valuable the audit trail becomes for investigations, the more important it is to separate logical deletion from physical storage recovery. That distinction should shape runbooks, maintenance windows, and recovery expectations before the table reaches a scale where normal administration stops being safe.

For practitioners

• Plan purge work in explicit maintenance windows Assume downtime if you are deleting a large volume of logs, and communicate the window before the first purge run begins.
• Run purges in staged retention passes Start with the oldest retention threshold that matches the system age, then step down in smaller passes instead of deleting everything older than one date.
• Separate disk reclamation from row deletion Use OPTIMIZE TABLE only when you truly need filesystem space back, because it can lock the table and require additional free capacity during the rebuild.
• Verify backups and snapshots before cleanup Take a fresh VM snapshot or verified full backup before any large purge so you can recover if lock times or timeouts exceed expectations.

Key takeaways

• Large action log tables can turn maintenance into a service-availability event rather than a routine admin task.
• The article distinguishes between deleting rows and reclaiming disk space, and those are not the same control.
• Staged purges, validated backups, and reliable maintenance windows are the controls that keep cleanup from breaking production.

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.
• Logical Deletion: The removal of records from application view without necessarily returning storage to the operating system. Databases may keep freed pages for reuse, so teams must not assume that deleting rows will immediately shrink the physical footprint of the table.
• 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.
• 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.

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.