In the default configuration, the process engine writes incidents to the process engine database. You may then query the database for different types and kinds of incidents using the exposed by the RuntimeService:

Incidents are stored in the ACT_RU_INCIDENT database table.

If you want to customize the incident handling behavior, it is possible to replace the default incident handlers in the process engine configuration and provide custom implementations (see below).

Incident Types

There are different types of incidents. Currently the process engine supports the following incidents:

• failedJob: is raised when automatic retries for a job (timer or asynchronous continuation) have been depleted. The incident indicates that the corresponding execution is stuck and will not continue automatically. Administrative action is necessary. The incident is resolved when the job is manually executed or when the retries for the corresponding job are set to a value > 0.

Creating and Resolving Custom Incidents

… or directly .

Custom incidents must always be related to an existing Execution.

An incident of any type, except for failedJob and failedExternalTask, can be resolved by calling RuntimeService#resolveIncident.

Incidents can be and resolved through the REST API as well.

(De-)Activate Incidents

• createIncidentOnFailedJobEnabled: indicates whether Failed Job incidents should be raised or not.

  Implement Custom Incident Handlers

Incident Handlers are responsible for handling incidents of a certain type (see ).

An Incident Handler implements the following interface:

The method is called when a new incident is created. The resolveIncident method is called when an incident is resolved. If you want to provide a custom incident handler implementation you can replace one or multiple incident handlers using the following method:

An example of a custom incident handler could be a handler which extends the default behavior by sending an email to an administrator whenever an incident of type failedJob occurs. However, just adding the custom incident handler overwrites the default behavior with the custom incident handlers behavior. As a consequence, the default incident handler is not executed anymore. If the default behavior should be executed as well, then the custom incident handler also needs to invoke the default incident handler, which includes using internal API.