Camunda 7 History Cleanup Strategy – Keep Production Fast & Stable
Introduction
In long-running production systems using Camunda 7, one of the most common hidden performance killers is uncontrolled history data growth.
Symptoms you may already have seen:
Cockpit and Tasklist becoming very slow
Database CPU usage increasing month by month
Simple queries on
ACT_HI_*tables taking seconds or minutesProduction incidents after a few months of go-live
👉 The root cause is almost always the same: no proper history cleanup strategy.
This blog explains:
How Camunda 7 history works
Why cleanup is mandatory in production
Available cleanup strategies
Step-by-step configuration
Best practices from real projects
How History Data Works in Camunda 7
Camunda 7 stores runtime and audit data in relational database tables.
Main history tables
ACT_HI_PROCINST– Process instancesACT_HI_ACTINST– Activity instancesACT_HI_TASKINST– User tasksACT_HI_VARINST– VariablesACT_HI_DETAIL– Variable updates
Every completed process instance adds rows to these tables.
🔷 Camunda 7 History Lifecycle (Conceptual Diagram)
Flow explained:
Without cleanup, the “Tables Shrink” step never happens.
Why History Cleanup Is Critical
What happens without cleanup
❌ Tables grow indefinitely
❌ Indexes become inefficient
❌ DB backups take longer
❌ Cockpit queries slow down
❌ Overall engine performance degrades
👉 History cleanup is not optional in production.
History Cleanup Options in Camunda 7
Camunda 7 provides built-in history cleanup, configurable in multiple ways.
Option 1: Time-To-Live (TTL) Based Cleanup (Recommended)
How it works
Define a TTL (Time-To-Live) for process definitions, cases, and decisions
Camunda deletes history older than the TTL
Example
All historic data older than 30 days is eligible for cleanup.
Where to Configure TTL
1️⃣ BPMN Model (recommended)
In process definition:
✔ Most precise
✔ Version-aware
✔ Best practice
2️⃣ Global Default TTL
In camunda.cfg.xml:
⚠️ Applies to all processes
⚠️ Less flexible
Option 2: History Cleanup Job
Camunda executes cleanup via a background job.
Job behavior
Runs periodically
Deletes history in small batches
Avoids long DB locks
🔷 Cleanup Job Execution – Diagram
Configuring the History Cleanup Job
Enable cleanup (Camunda 7.4+)
Configure cleanup window (important)
✔ Run cleanup during low-traffic hours
✔ Avoid peak business time
Configure batch size
✔ Smaller batch = less DB load
✔ Larger batch = faster cleanup
Option 3: Manual / Script-Based Cleanup (Advanced)
Used when:
Migrating old systems
Emergency DB cleanup
One-time large purge
⚠️ Not recommended for daily operations
⚠️ Risky without DB expertise
Common Production Mistakes 🚨
❌ No TTL defined
❌ TTL set but cleanup job disabled
❌ Cleanup running during peak hours
❌ Very large batch size
❌ Relying on manual DB deletes
❌ Ignoring indexes on history tables
Performance Best Practices
✔ Always define TTL per process
✔ Prefer 30–90 days retention (business-dependent)
✔ Enable cleanup jobs early (day one)
✔ Schedule cleanup at night
✔ Monitor cleanup job duration
✔ Index END_TIME_, PROC_DEF_KEY_, REMOVAL_TIME_
✔ Combine cleanup with archiving strategy if needed
Monitoring History Cleanup
What to monitor
Cleanup job duration
Rows deleted per run
DB load during cleanup
Growth rate of
ACT_HI_*tables
Interview Question (Very Common)
Q: What happens if history cleanup is not enabled in Camunda 7?
A: History tables grow indefinitely, causing database and engine performance degradation over time.
Real-World Recommendation
| Environment | Strategy |
|---|---|
| Dev / Test | TTL = 7–14 days |
| QA / UAT | TTL = 30 days |
| Production | TTL = 60–90 days (business-driven) |
Conclusion
A proper history cleanup strategy is mandatory for any serious Camunda 7 production system.
Key takeaways:
History data grows fast
Cleanup must be planned from day one
TTL-based cleanup + scheduled jobs is the safest approach
Poor cleanup = guaranteed performance problems later
👉 If Camunda feels “slow after a few months”, history cleanup is usually the reason.
💼 Professional Support Available
If you are facing issues in real projects related to enterprise backend development or workflow automation, I provide paid consulting, production debugging, project support, and focused trainings.
Technologies covered include Java, Spring Boot, PL/SQL, Azure, and workflow automation (jBPM, Camunda BPM, RHPAM).
📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 Website: IT Trainings | Digital metal podium
Comments
Post a Comment