A Mirth Connect message pruner that looks enabled can still silently fail to clear messages because of an oversized block size, a disabled or misconfigured schedule, missing indexes on the message table, or a pruning rule that excludes errored and queued messages. Fix it by reducing the block size, re-enabling and verifying the schedule, adding supporting indexes, and deliberately deciding whether errored messages should be included. Prevent recurrence by tracking message table row count over time rather than trusting the pruner's own configuration screen.
Quick answer
A Mirth Connect message pruner not running shows up first as a growing message table and climbing disk usage, not as an error in the log — the pruner is configured, appears enabled, and simply isn't clearing anything. It's a quiet failure usually only noticed once storage becomes a real problem.
Below is what actually stops the pruner from doing its job, how to get it running again, and how to catch it happening again. Our free Mirth Health Check can confirm whether the pruner is actually executing — part of the Mirth Connect support work we do for US healthcare teams.
What Causes the Message Pruner to Stop Working?
The pruner runs as a scheduled job against the message store, and it can silently fail to make real progress for reasons that have nothing to do with whether it's technically "enabled" in the settings screen. Most causes come down to either the prune query timing out before it finishes a block, or the pruning rule excluding a larger share of messages than anyone expected when it was first configured.
Pruner Block Size Too Large for the Message Volume
The pruner processes messages in blocks, and a block size too large for your table can cause each run to time out before completing. The job appears to run but never finishes a full pass, so the table keeps growing.
Pruner Schedule Disabled or Misconfigured
A pruner schedule that was disabled during a maintenance window and never re-enabled will show as configured but simply never fire. This is easy to miss because the settings page still displays the pruning rule as if it's active.
Missing Database Indexes Slowing the Prune Query
Without proper indexes on the message table's date or status columns, the prune query becomes slow enough to time out or get skipped under load, especially as the table grows larger than when the pruner was first configured.
Errored or Queued Messages Excluded From Pruning
By default, many pruning rules exclude errored or queued messages so they aren't lost accidentally, but if a channel accumulates a large volume of errors that are never resolved, those messages sit permanently outside the pruner's reach and keep growing.
How to Fix a Pruner That Isn't Running
Confirm first whether the pruner is actually executing and failing partway through, versus configured correctly but simply excluding the category of messages that's filling the table, since the fix is different for each scenario. The four fixes below map directly to the four causes above, so match the symptom you've actually confirmed before changing a setting that won't address it.
Reduce the Pruner Block Size
Lowering the block size trades a longer overall prune time for each individual run completing successfully instead of timing out. Start with a noticeably smaller value and increase it gradually once you confirm full passes are completing.
Re-Enable and Verify the Pruner Schedule
Check the pruner's schedule settings directly rather than assuming it's running because it was configured months ago, and confirm the next scheduled run time is actually in the future, not stuck on a past date.
Add Indexes to Support the Prune Query
Adding indexes on the columns the prune query filters by, typically message date and status, is one of the highest-impact changes for a pruner that's timing out on a large table. Test this on a staging database first if possible.
Include Errored Messages in the Pruning Rule
If errored or queued messages are the bulk of what's accumulating, decide deliberately whether to include them in pruning after a defined retention period, rather than leaving the default exclusion in place indefinitely by accident.
How to Prevent This From Happening Again
The underlying pattern here is a pruner that quietly stops making progress without anyone noticing until storage becomes genuinely urgent, so prevention is about visibility into the message table's actual growth rate rather than just trusting what the pruner's configuration screen claims.
Track Message Table Row Count Over Time
A simple scheduled query logging the message table's row count gives you an early trend line that will flag a stalled pruner weeks before disk space becomes a genuine emergency.
Run the Pruner During Off-Peak Hours
Scheduling the pruner to run during your lowest-traffic window reduces the chance of it competing with production queries for database resources, which lowers the odds of a timeout in the first place.
Separate Content Pruning From Message Pruning
Mirth distinguishes between pruning message content and pruning the message metadata itself — understanding which one your rule actually targets prevents the common mistake of thinking messages are gone when only their content has been cleared.
Periodically Vacuum or Reindex the Database
Database maintenance tasks like vacuuming or reindexing keep the prune query itself performing well as the table grows and shrinks repeatedly, which matters more on databases that don't reclaim space automatically after large deletes.
When to call for help
If you've reduced the block size and confirmed the schedule and the table still isn't shrinking, the cause is usually a missing index or an exclusion rule that's easy to overlook without direct access to the query plan. Our free Mirth Connect health check confirms whether the pruner is completing full passes as part of the standard diagnostic.
Seeing an error alongside it? Send us the log, or check pricing for ongoing support plans.
Not sure your pruner is actually working? Free Mirth health check — a written 12-point audit report in 48 hours, no cost.