- Resources
- Monitoring
Camunda process monitoring that people outside IT can use
3 min read · Updated Nov 11, 2026
Monitoring a Camunda 8 process means more than watching for errors. What to track, who needs to see it, and how to spot trouble before a client does.
Two audiences, two questions
Engineers ask: is the engine healthy, and did anything fail? Operations ask: where are our cases, and are we on time? Both are monitoring, but they need different views.
Camunda 8 covers the first well. Operate shows process instances, where each one stands on its diagram and which ones have incidents, and lets you retry them. Optimize adds reports and analysis on top. These tools are built for people who know Camunda.
The second audience (process owners, team leads, managers) usually ends up asking IT for screenshots or exports, because they do not have access to Camunda's tools or do not want to learn them.
What to watch
Incidents. An incident is a step the engine could not complete: a worker threw an error, a variable was missing, a service was down. Each one is a case that has stopped. Track how many are open, where they occur, and how long they stay open.
Volumes. How many cases started, completed and failed over a period. A sudden drop in starts can mean a broken form long before anyone complains.
Durations. How long cases take end to end, and how long each step takes. Averages hide the cases that take ten times longer, so look at the slow ones too.
Deadlines. How many tasks are late or due today, and for which team.
Workload. How many open tasks each person holds, and how many nobody has claimed.
Show the case on its diagram
A list of instances tells you something is wrong. The diagram tells you where. Seeing a case as a token on its real BPMN diagram, with the failed step highlighted, turns "case 1042 is stuck" into "case 1042 is waiting at the credit check because the scoring service timed out". That is something a process owner can act on, or route to the right engineer.
Do not wait for the complaint
The most expensive way to learn about a failure is from a client. Good monitoring pushes the important things to people instead of waiting for them to look:
- a notification centre for what needs attention now;
- an alert when a task arrives or a deadline is at risk;
- a short periodic report for people who only need the summary.
Keep it in one place
When monitoring lives in one tool, tasks in another, forms in a third and reports in spreadsheets, nobody has the whole picture. Putting the inbox, the live cases and the numbers in one place, with each person seeing what their role allows, is what makes monitoring a habit rather than an investigation.
In Bridge
Bridge shows every instance moving on its real BPMN diagram. Incidents surface on the diagram with their error context and a one-click retry, and the notification centre lists what needs attention.
The dashboard shows volumes, failures and durations over any time range, the workload view shows who holds which tasks, and weekly PDF reports go to management and auditors. Each person only sees the menus their role allows, so process owners get the view they need without Camunda access.