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 minutes

  • Production 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 instances

  • ACT_HI_ACTINST – Activity instances

  • ACT_HI_TASKINST – User tasks

  • ACT_HI_VARINST – Variables

  • ACT_HI_DETAIL – Variable updates

Every completed process instance adds rows to these tables.


🔷 Camunda 7 History Lifecycle (Conceptual Diagram)

Flow explained:

Process Execution → History Written → Data Retained → Cleanup → Tables Shrink

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

TTL = 30 days

All historic data older than 30 days is eligible for cleanup.


Where to Configure TTL

1️⃣ BPMN Model (recommended)

In process definition:

History Time To Live: 30

✔ Most precise
✔ Version-aware
✔ Best practice


2️⃣ Global Default TTL

In camunda.cfg.xml:

<property name="historyTimeToLive">30</property>

⚠️ 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

Scheduler → Cleanup Job → Batch DeleteCommit → Repeat

Configuring the History Cleanup Job

Enable cleanup (Camunda 7.4+)

<property name="historyCleanupEnabled">true</property>

Configure cleanup window (important)

<property name="historyCleanupBatchWindowStartTime">01:00</property> <property name="historyCleanupBatchWindowEndTime">05:00</property>

✔ Run cleanup during low-traffic hours
✔ Avoid peak business time


Configure batch size

<property name="historyCleanupBatchSize">500</property>

✔ 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

EnvironmentStrategy
Dev / TestTTL = 7–14 days
QA / UATTTL = 30 days
ProductionTTL = 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.

💼 Need Help with Camunda, Jira, or Enterprise Workflows?

I help teams solve real production issues and build scalable systems.

Services I offer:
• Camunda & BPMN workflow design and debugging  
• Jira / Confluence setup and optimization  
• Java, Spring Boot & microservices architecture  
• Production issue troubleshooting  


📩 Email: ishikhanirankari@gmail.com | info@realtechnologiesindia.com

✔ Available for quick consulting calls and project-based support
✔ Response within 24 hours

🎥 Learn IT with Shikha on YouTube

Prefer learning through videos? Watch practical tutorials on Kafka, Camunda, Alfresco, Java, Spring Boot, Microservices and Enterprise Architecture.

▶ Subscribe to Learn IT with Shikha on YouTube

Comments

Popular posts from this blog

Top 50 Camunda BPM Interview Questions and Answers for Developers (2026 Guide)

10 BPMN Best Practices Every Camunda Developer Should Know

OOPs Concepts in Java | English | Object Oriented Programming Explained