Camunda 8 Tasklist UI - Slow UI performance

Camunda 8 Topics
1

Hello. I am using the Camunda 8.8 local setup with helm.

In the Tasklist UI, I am noticing that the UI is too slow. For example, when I press “Assign to me” on a user task, it takes around 5 seconds to actually assign it to me.

It seems that this happens due to an asynchronous polling call made by the browser, invoking http://localhost:8080/v2/user-tasks/search, which occurs every 5 seconds, and updates the UI accordingly. This means that whatever action I do in the Tasklist UI, it might take up to 5 seconds to update the view in the UI.

In general the UI of Camunda 8 seems sluggish, everything loads for too long:

  1. Starting a process takes 5+ seconds.
  2. Assigning a task to me takes 5~ seconds.
  3. After completing a user task, it might take 5+ seconds to be removed from the view.

Can I make the Tasklist UI more responsive somehow?

2

Hi @Nikos_M,

Thank you for the detailed description of the performance issue you’re experiencing with Camunda 8.8 Tasklist UI. This is a known behavior related to Camunda 8’s architecture, and I can explain what’s happening and provide some solutions.

Root Cause

The 5+ second delay you’re observing is primarily due to Camunda 8’s eventually consistent architecture:

  1. When you perform actions (assign tasks, start processes, complete tasks), Zeebe processes them immediately
  2. However, the Tasklist UI relies on data that must flow through: Zeebe → Elasticsearch → Tasklist indexing
  3. This export and indexing process introduces the delay you’re seeing, regardless of the UI polling interval

The browser polling you noticed (/v2/user-tasks/search every 5 seconds) is just when the UI checks for updates, but the real bottleneck is the data availability in Elasticsearch.

Configuration Limitations

Unfortunately, there are no documented configuration options in the Helm chart or Tasklist settings to:

  • Adjust the UI polling/refresh interval
  • Speed up the Zeebe → Elasticsearch → Tasklist data flow significantly

Even with more aggressive exporter settings (like lowering ZEEBE_BROKER_EXPORTERS_ELASTICSEARCH_ARGS_BULK_DELAY), users typically still report 5-8 seconds until tasks/variables become visible.

Recommended Solutions

For applications requiring more responsive UIs, the community has identified several patterns:

1. Event-Driven Architecture (Recommended)

Instead of relying on Tasklist polling:

  • Use execution listeners or user task lifecycle events to notify your application when tasks are created/completed
  • Implement your own application database to mirror process state
  • Drive your UI from this local state rather than Tasklist APIs

2. Hybrid Approach

  • Handle immediate UI feedback in your application layer
  • Use Tasklist for task management but not for real-time state updates
  • Implement optimistic UI updates with eventual consistency

3. Accept the Delay

  • Implement proper loading states and user feedback
  • Set user expectations about the processing time
  • Use retry mechanisms with reasonable timeouts

References

This behavior is well-documented in the community:

The key takeaway is that Zeebe is designed for reliability and scalability rather than sub-second UI responsiveness. For highly interactive user experiences, you’ll need to implement your own state management layer alongside Camunda.

Would you like me to elaborate on any of these architectural patterns or help you think through which approach might work best for your use case?