Camunda 8 deep dive: deployment, observability and incident runbooks

With SaaS, the provider manages the hosted platform, but your team still owns deployed models, worker services, integration endpoints, machine credentials and business recovery. Document how workers connect from your network and which dependency failures remain your responsibility.

Self-Managed adds responsibility for supported infrastructure, identity configuration, persistent storage, capacity, patching and recovery. Use the deployment guide for the exact release and topology. Component packaging, APIs and supported search or storage backends evolve; do not build an installation by mixing commands from unrelated versions.

Separate development, staging and production access. Give each worker and connector runtime the necessary machine credentials and no broader privileges than required. Confirm ingress, egress, TLS and the secret provider supported by that runtime.

Plan rotation before an outage: test that updated credentials are loaded through the documented mechanism and that old credentials can be revoked safely. Do not put secrets into BPMN variables, exported diagrams, screenshots or incident evidence. Connector secret-provider syntax and runtime configuration depend on deployment mode.

Observe incident counts, oldest waiting job age, job handling latency, active worker capacity and downstream throttling. Compare process arrivals with completion rates to identify accumulating work. A running pod or successful HTTP health check does not prove requests are finishing.

Use process instance keys, request IDs and operation IDs to correlate worker logs with process activity. Avoid unbounded high-cardinality labels in metrics and redact personal data from logs. Choose alert thresholds from measured workload and agreed service objectives rather than copying arbitrary values.

Locate the failing element in Operate and record the process definition version and redacted error details. Determine whether the cause is unavailable workers, a mismatched job type, exhausted retries, invalid variables, a failed expression, authentication or downstream access.

For a worker outage, restore the compatible worker and check job age. For exhausted retries, repair the cause and use authorised controls to update retries or resolve the incident as required by that version. For uncertain external outcomes, reconcile before resuming; bulk retry can multiply financial or operational side effects.

For Self-Managed, use the officially supported coordinated backup and restore procedure for the installed architecture. Do not assume copying one database or taking an arbitrary volume snapshot captures consistent engine and secondary state. Practise restore in isolation and verify that representative process state and operations are recoverable.

Define recovery-time and recovery-point objectives with the organisation, then measure the rehearsal against them. Coordinate process history retention, external documents and audit obligations; keeping everything forever is not a substitute for an approved retention policy. SaaS backup capabilities and customer recovery options must be checked against the service documentation and agreement.

Run an authorised sandbox exercise with a failed dependency, restore service and reconcile the external operation. Confirm the instance reaches its intended state and the downstream system has no duplicate action. Observe whether backlog returns to normal without saturating the dependency.

Record the recovery owner, trigger, evidence, remaining risks and escalation route. A restarted service is only an intermediate step; the recovery is complete when the affected business records and process state agree.