How the Flowable actuator endpoint shows running processes
The Flowable Spring Boot starters expose an actuator endpoint at /actuator/flowable that reports on running processes. If your team runs Flowable inside a Spring Boot service, this is the quickest way to see whether process instances are starting, still running and finishing, without querying the history tables by hand. The endpoint is the right first stop for a dashboard or a health check. Logs answer what happened to one instance, JMX is better suited to operating the engine (for example, toggling the job executor), and history queries are the tool for reconstructing past behavior or building reports. The endpoint reports on the engine's current state, so it does not replace them.
Before you rely on it, confirm three things for your version. First, that the starter you use provides the actuator endpoint for the engine you deploy, since the Flowable Spring Boot docs describe starters for each engine and for REST, and the Spring Boot baseline has changed across Flowable releases. Second, which fields and counts the response contains, because the docs describe the endpoint in general terms and the exact output may differ by engine. Third, how the endpoint is enabled and exposed in your application's actuator configuration. Check the Flowable Spring Boot documentation and test the endpoint in a non-production environment before wiring it into alerts.
Treat the endpoint as an operations surface, not a public one. Actuator endpoints can reveal internal process names and volumes, so restrict who can reach them through network policy, the management port or your gateway, and confirm that your security model covers them. Then feed the values into the monitoring you already run, such as your metrics scraper or dashboard tool, and set alerts on trends that matter to your process owners, for example a count of running instances that keeps rising while completions flatline. Agree the thresholds with the business owners of each process so that a rising count is read as a signal rather than as noise.
Which actuator settings fit your monitoring stack
This table compares the starter you choose, how Spring Boot exposes the endpoint over HTTP, and whether your team reads the data directly or scrapes it into a metrics store. Read each row against your existing monitoring tooling and access model. The main takeaway is that the starter sets what data exists, while exposure and scraping decide who can reach it and how much upkeep it creates.
| Setting | Option and when it fits | Access control and maintenance cost |
|---|---|---|
| Starter that brings the endpoint | Starter for all engines fits teams running BPMN, CMMN and DMN together. Individual process, CMMN or DMN starters fit services that run only one engine. | Confirm which engines report to the endpoint in your version. Each starter you add changes the dependency set and must be retested on upgrade. |
| Starter for REST | Choose this when the service also exposes the Flowable REST API and you want one dependency set for both. | The REST API has its own authentication needs, separate from the actuator. Confirm both surfaces are secured independently. |
| HTTP exposure through Spring Boot | Exposing the endpoint over HTTP fits teams that scrape with Prometheus or read with a central collector. | Exposure must be set in configuration on purpose. Confirm the management port, network path and authentication before any scraper reaches it. |
| Direct reads by operators | Direct reads fit small teams that check counts during incidents and do not run a metrics pipeline. | Operators need credentials and an audit trail. Each extra user or tool adds access reviews to the recurring workload. |
| Scraping into a metrics store | Scraping fits organizations already running Prometheus, Grafana or a similar store, where alerts and dashboards must live beside other services. | Plan for a scrape job, label naming, dashboard upkeep and retention. Expect the metric names to be checked again after each Flowable version change. |
| Management port separated from the application | Separating the management port fits services where the public API must never expose operational data. | Network policies, service definitions and firewall rules need maintenance. Confirm the port is unreachable from outside the cluster or network segment. |
| Counts for running and completed work | Use the endpoint's counts of process definitions, running instances and completed tasks for trend lines and simple thresholds. | Counts reflect engine state, not business outcomes. Confirm with your engineers which counts map to the alerts your operations team needs. |
What process counts, running instances and completed tasks mean
The endpoint at /actuator/flowable reports counts for process definitions, running process instances and completed tasks, and each category answers a different question. A running instance is a process instance that has not yet ended, so it may be waiting at a user task, a timer, an async job or a call to another service. An active task is a user task that currently exists and has not been completed. One running instance can own zero, one or several active tasks, so a task count will not match an instance count, and a rise in one does not imply a rise in the other. Before you build alerts, confirm in your Flowable version exactly which fields the endpoint returns (the names and whether they are totals or per-definition values), because the Spring Boot docs describe the endpoint without listing every field in the text this page relies on.
Counts move for reasons that are not always failures. During a deployment, new definition versions appear while older instances keep running on their original versions, so the running total can stay flat while the mix of definitions shifts. A job backlog works differently: instances stop advancing at async steps and timers, so running counts climb while completed counts slow. The async executor stores lock owners and lock expiration times in the database, and expired locks are picked up by other nodes, so a count that drops and then recovers after a node restart may reflect that recovery rather than lost work. Compare the endpoint with the job tables before treating a movement as an incident.
Use the endpoint as a fast signal and the database as the record. Completed counts should be checked against the history tables if your history level keeps them, because the endpoint is a point-in-time view and history is what supports reconstruction. The endpoint does not replace event logging or audit evidence: it does not show who started an instance, which variables changed, or why a decision returned a value, so compliance evidence still comes from history, the event logger or your own audit trail. Plan the reading as a checklist: confirm the field set in your version, sample counts against the job and history tables during a known deployment window, and record the thresholds your operations team will act on.
Exposing the Flowable actuator endpoint safely
The actuator endpoint reveals how many process definitions, running instances and completed tasks your organization operates, which is useful to operators and sensitive to anyone else. The cards below cover who can read that data, how the endpoint is reached, and how to keep the surrounding actuator surface small and maintained.
Decide who can read instance counts
Process counts and running instance totals show workload, business volume and which processes are active. Treat them as operational data that the monitoring team needs and that most application users do not. Confirm which identities and service accounts scrape the endpoint, and record who owns each one. Check whether the same counts are visible through any other route, such as a dashboard or a shared report, so the access review covers every path to the data.
Keep the endpoint off the public network
Confirm that the actuator path is reachable only from the monitoring network or from the scrape job's address range. Test this from outside the cluster and from a user-facing subnet, not only from inside the service. A path that works through the public ingress is the most common exposure, because the application route often forwards every path under its prefix. Document the expected reachability so a later routing change is caught by a test.
Restrict actuator paths at the proxy
Allow only the actuator paths the monitoring system needs, and block the rest at the reverse proxy, ingress or service mesh. Actuator exposes several endpoints beyond Flowable, so a prefix rule that passes the whole /actuator tree widens the attack surface. Write the allow list as a reviewed configuration file, and test that denied paths return a refusal from the edge rather than from the application.
Separate the management port
Spring Boot can serve actuator endpoints on a separate management port, which keeps monitoring traffic away from the application listener. Ask your platform team whether the management port is reachable only inside the cluster or network segment, and whether network policies enforce that. Confirm the setting against the Spring Boot documentation for your release, since property names have changed across major versions. Record the port in the same configuration review as the proxy rules.
Rotate scrape credentials on a schedule
If the scrape job authenticates with a token or password, set a rotation schedule and an owner. Store the credential in your secrets manager rather than in the scrape configuration file, and confirm that rotation does not require a restart of the engine. Revoke credentials for engineers who change roles, and watch for failed scrapes after rotation, which often signal a missed update.
Review enabled actuator endpoints together
Each enabled actuator endpoint adds exposure, so review the full list at each release and after each dependency change. Keep only the endpoints your monitoring and operations use, and confirm that sensitive endpoints such as environment or heap dumps are not exposed by default. Ask the vendor or your integrator to list which endpoints a new Flowable starter adds, because the set can change with the Spring Boot version your team runs.
Enabling the Flowable actuator endpoint in Spring Boot
This sequence takes a Spring Boot application from no Flowable monitoring to a working /actuator/flowable endpoint that returns counts you can verify, with access restricted to the hosts and identities you approve.
Confirm the Flowable and Spring Boot version pair
The engineer responsible for the application checks the Flowable release against the Spring Boot version in the build file before changing anything. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 and dropped support for Spring Boot 3, while Flowable 7.x runs on Spring Boot 3 with Java 17 and Jakarta EE. Confirm the pairing in the Flowable Spring Boot documentation and the release notes for your version. The step is done when the team has written down one Flowable version and one Spring Boot version that the documentation supports together.
Add the Flowable Spring Boot starter
Add the Flowable starter that matches your engine and version to the build file, using the dependency management your team already uses. Choose the all-engines starter or the individual BPMN, CMMN or DMN starter, depending on which engines the application runs. Build the project and confirm that the dependency tree resolves without conflicting Spring or Jackson versions. The check is a clean build and a dependency report that shows one version of each Flowable artifact.
Enable only the endpoints you need
In the application configuration file, expose the actuator web endpoints that the monitoring team requires, and leave the rest disabled. Set the exposure list to include flowable only if the team plans to read it, and keep management endpoints on a separate port or internal interface where your platform supports it. Record each property in version control so the change can be reviewed. The check is a diff that lists the exposed endpoints explicitly, with no wildcard exposure.
Start the application against a known deployment
Deploy a small set of process definitions to a test database whose contents you know in advance, then start the application. Watch the startup log for engine initialization errors and confirm the schema matches the engine version. Note the number of deployed definitions and any instances you start manually. The check is a clean startup with no database version or schema errors, and a written list of the expected counts that you will compare in the next step.
Confirm the endpoint appears in the actuator index
Request the actuator index from an approved internal host and confirm that the flowable entry appears in the list of exposed endpoints. If it is missing, check the exposure property, the starter on the classpath, and whether the application context loaded the Flowable auto-configuration. The step is done when the index shows the endpoint and the response from /actuator/flowable returns without error.
Compare endpoint counts with the known deployment
Call /actuator/flowable from an allowed host and compare the process counts, running instances and completed tasks with the figures you recorded for the test deployment. Start one new instance, complete one task, and call the endpoint again to confirm that the values move in the expected direction. A mismatch usually points to the wrong database, a deployment that did not finish, or a stale application instance behind a load balancer. The step is done when the values match your expectations after each controlled change.
Verify that unauthenticated and disallowed access is refused
Request the endpoint without credentials and from a host outside the approved network range, and confirm that the application refuses both. Apply your standard authentication for actuator paths, such as a management security filter or network policy, and retest after each change. Confirm the Flowable documentation and your security team's guidance on what the endpoint reveals, because process and instance counts can expose business activity. The step is done when refused requests are logged and approved requests succeed.
Record the configuration and confirm the monitoring feed
Document the starter version, exposed endpoints, access rules, and the verified baseline counts in the team's runbook, then point the existing monitoring tool at the endpoint with the agreed scrape interval and credentials. Ask the monitoring owner to confirm that the first samples arrive and match the values you checked by hand. The step is done when the monitoring system shows the same counts as your manual check and the runbook lists who owns the configuration.
Feeding actuator data into existing monitoring
If your platform team already runs Prometheus, the most direct route is to expose the Flowable metrics in a format the scraper can read and let Prometheus poll them on a fixed interval. The actuator endpoint returns JSON, so the team usually adds a small exporter or a bridge that converts the counts into time-series samples. Confirm with your Spring Boot version and metrics library how the endpoint data is mapped to metric names and labels before you write any dashboards against them.
- Scrape interval: Choose the poll frequency as a sizing decision. Test the load the endpoint adds to the engine database, since each poll runs count queries against process and task tables.
- Metric naming: Agree on names and labels for process definition, running instance and completed task counts so that alert rules survive a rename in the application.
- Alert rules on counts: Define alerts on rates of change and on thresholds for running instances, such as a sustained drop to zero for a process that should always have traffic. Set the window with the business owner.
- Scrape failures: Alert when the target is down or the endpoint returns an error, because a silent gap looks like a healthy zero.
- Pre-live testing: Confirm that counts rise and fall when you start and complete test instances in a non-production environment, and that each alert fires once and resolves.
Before going live, check that the scraper credentials are scoped to read-only access on the management port.
If your team already runs Grafana with data sources for logs, metrics or a relational database, you can build Flowable dashboards on top of those sources rather than adding a new collector. The choice depends on which source already holds the engine counts. If the counts reach Grafana through Prometheus or another store, the dashboard reads from there. If you use a JSON data source plugin that calls the endpoint directly, confirm that the plugin is approved by your security team and that it supports the authentication your endpoint requires.
- Polling path: Decide whether Grafana queries the endpoint directly or reads counts that another job already stored. Direct polling adds load on each dashboard refresh, so set refresh intervals deliberately.
- Dashboard scope: Build panels for running instances by process definition, completed tasks over time and the gap between the two, so the team sees trends rather than a single snapshot.
- Alert rules on counts: Use Grafana alerting on the same query used by the panel. Keep the threshold and the evaluation window in version control with the dashboard.
- Data source permissions: Restrict which folders and users can edit the data source, since it holds credentials for the management endpoint.
- Pre-live testing: Compare panel values against counts read directly from the endpoint for a known set of test instances. Confirm that alerts route to the on-call channel and that dashboards show a clear no-data state.
Before going live, confirm who owns the dashboard after the build team leaves.
Some organizations run a commercial observability platform or an internal aggregator that accepts a generic HTTP check and parses JSON responses. This model needs the least new infrastructure, but it depends on how the platform schedules checks and how it maps fields into metrics. Confirm the response shape with your Flowable version before writing field mappings, because a later upgrade can change the JSON structure of the endpoint.
- Polling method: Configure an authenticated HTTP check against the endpoint from a host inside the network that can reach the management port. Do not expose the port to the internet to make the check work.
- Field mapping: Map the JSON fields for process counts, running instances and completed tasks to named metrics. Store the mapping in the same repository as the deployment pipeline so that changes are reviewed.
- Alert rules on counts: Set thresholds on the mapped metrics, and add a rule for check failures or unparseable responses, which often appear after a version change.
- Credentials and transport: Store the check credentials in your secrets manager and use TLS between the check runner and the endpoint.
- Pre-live testing: Run the check through a simulated engine outage and a changed field name in a test environment. Confirm that the alert fires and that the platform reports a parse error rather than zero counts.
Before going live, check that the platform's retention settings meet your operations and audit needs.
Limits to confirm in your environment
The actuator endpoint looks simple, but its behavior depends on the Flowable release line, the Spring Boot baseline, the size of your history tables and how your nodes are deployed. Confirm each limit below against your own versions and data before you build dashboards or alerts on the numbers.
Release line and Spring Boot baseline
Flowable 8.0.0 was released on February 27, 2026, and it moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. An application on Spring Boot 3 cannot simply take the 8.x starter, so the endpoint you test against depends on the release line you run. Confirm which starter and Spring Boot version your application uses, and test the endpoint on that exact combination before promoting it.
Fields returned per version
The counts the endpoint reports, such as deployed process definitions, running instances and completed tasks, are not guaranteed to keep the same names or structure across releases. Capture the JSON response from each Flowable version you run and store it as a reference. Any dashboard query that parses a field name should be tested again after every upgrade, because a renamed key fails silently in many monitoring tools.
Query cost on large history tables
Counts of completed tasks and historic instances read from history tables, which can grow large in long-running systems. Ask your DBA to check the execution plan for the queries behind the endpoint against a copy of production-sized history data. Set a scrape interval that matches what the database can absorb, and do not let a monitoring tool poll the endpoint more often than the query cost justifies.
Per-engine or per-application counts
If your application starts more than one Flowable engine, for example a process engine and a CMMN engine in the same JVM, confirm whether each reported figure covers one engine, one application or the combination. Mixing these scopes produces totals that look correct but double count or omit instances. Write down the scope of each metric before it appears on a shared dashboard.
Behavior across cluster nodes
Flowable nodes in a cluster share one database, so a count read from one node usually reflects shared state, but live values such as executor status can differ per node. Confirm whether the endpoint reports cluster-wide figures or only the node that answered the request. Then configure your scraper to collect from every node or from a load-balanced address, and label each series with its node so gaps are visible.
Questions teams ask before monitoring Flowable through actuator
How much effort does setting up the Flowable actuator endpoint take?
For most Spring Boot applications that already run Flowable, the endpoint itself is a small configuration change. The effort comes from the surrounding work: deciding which counts matter, restricting who can reach the endpoint, and wiring the figures into dashboards and alert rules your operations team already uses. Effort rises when the engine runs in several services, when each service has its own owner, or when the monitoring stack is not yet defined. Ask any partner to split the quote into endpoint configuration, access control, dashboard and alert design, and handover so you can see which parts your own team could absorb.
Can our internal team set up Flowable actuator monitoring alone?
Often yes, provided the team already knows Spring Boot and has Flowable running with the Spring Boot starters. The Flowable Spring Boot documentation describes the /actuator/flowable endpoint for monitoring running processes, so the engine side is well documented. Internal teams usually struggle with three things: deciding what a healthy process count looks like for their workload, keeping the endpoint off public networks, and maintaining the alert thresholds over time. If none of those has an owner today, an outside partner can help define them, but the decision of what to alert on should stay with your operations team.
What does the work need from our side before it starts?
Confirm four things before scoping. First, the Spring Boot version your Flowable services run, because the actuator starter must match it. Flowable 8.0.0 targets Spring Boot 4 and does not support Spring Boot 3, so an application on Spring Boot 3 needs a different plan. Second, network access: which management port, which subnets or service mesh routes can reach the endpoint, and whether your monitoring collector can scrape it. Third, named monitoring owners who will receive the data and act on alerts. Fourth, the environments in scope, such as development, test and production.
How long does an actuator monitoring engagement take?
Duration depends on scope, not on a fixed number of days. The main variables are how many Flowable services and engines are involved, whether the endpoint needs to be exposed in more than one environment, how many dashboards and alerts must be built, and how many teams must review the results. A single service feeding an existing Prometheus or Grafana setup is a much smaller piece of work than a platform with several engines, separate network zones and formal change approval. Request a timeline in the written scope that lists each milestone and the reviews it depends on.
What drives the cost of a partner-delivered monitoring setup?
A partner charges for the time its engineers spend on the agreed scope, so cost follows the same drivers as effort: the number of engines and services, the complexity of the access model, the number of monitoring tools receiving data, and how much validation your change process requires. One-time work includes the initial configuration, access review and dashboard build. Recurring costs are internal: someone must keep alert thresholds current after Flowable upgrades and after process volume changes. DeployOpen does not publish a price list, so ask for a quote built from a written scope that names each of these components.
Is it safe to expose the Flowable actuator endpoint in production?
Treat the endpoint as internal operational data. It reveals process activity, so it should not be reachable from public networks or from application users. Restrict it to a dedicated management port or a monitoring network, require authentication where your platform supports it, and confirm which actuator endpoints are enabled alongside the Flowable one. Review the exposure settings with your security team before go-live, and record the decision in your change records. Flowable's security guidance covers authentication and access control for engines and APIs, which should be read alongside your own network policy.
What does an outside partner typically quote for this work?
A typical quote breaks into discovery, configuration and access design, dashboard and alert build, integration with your existing monitoring stack, testing in each environment, and handover. Each part is priced from the written scope, so the same endpoint can cost very different amounts depending on how many services and environments are covered. Ask the partner to state assumptions, the people it expects from your side, what is excluded, and which items are optional. Quotes for fixed-scope work are agreed in writing before work starts, and ongoing monitoring support can be arranged as a separate retainer.
How DeployOpen scopes and supports Flowable monitoring
DeployOpen plans, builds and hands over Flowable monitoring inside your own infrastructure, so the actuator endpoint is exposed deliberately and its data reaches the dashboards and alerting your operations team already uses. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Inventory the Flowable engines, Spring Boot starters and deployments that the actuator endpoint would cover in your environment
- Decide which metrics your operations team needs for process counts, running instances and completed tasks
- Record who may reach the endpoint, the network path it uses and the authentication method agreed for it
- Confirm which existing monitoring tools will receive the data and who owns the alert thresholds
How we build
- Enable the actuator endpoint at /actuator/flowable in a non-production environment and verify the reported values against known process activity
- Restrict exposure through actuator settings, network policy and the security controls your identity provider supports
- Connect the endpoint to your existing metrics collection and build dashboards and alert rules from the agreed metrics
- Test the monitoring against normal load and against a stopped or stuck engine to confirm the signals behave as expected
How we hand over
- Deliver a written configuration record covering exposed properties, access rules and the scraping or collection setup
- Document what each reported count means, including how running and completed figures should be read during investigations
- Provide runbook steps for responding to each alert, with links to related Flowable troubleshooting work your team may need
- Walk your operators through the dashboards and the process for changing thresholds or access rules
How we support
- Review monitoring coverage when Flowable versions change, since the Spring Boot baseline differs between major releases
- Apply endpoint configuration changes through your normal change process and retest exposure after each change
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants DeployOpen to keep monitoring current
- Confirm support scope, response expectations and what is covered before the retainer begins
