Understand Runnable vs. Flowable Tasks in Your Flows

For the complete documentation index, see llms.txt. For a full content snapshot, see llms-full.txt. Append .md to any kestra.io/docs/* URL for plain Markdown.

Tasks are the discrete steps within a flow that process inputs, run logic, and produce outputs.

Flowable tasks

Kestra orchestrates flows using Flowable tasks. These tasks do not perform heavy computation. Instead, they control orchestration behavior, enabling advanced workflow patterns.

Example Flowable tasks include:

  • io.kestra.plugin.core.flow.Parallel
  • io.kestra.plugin.core.flow.Switch
  • io.kestra.plugin.core.flow.Loop

Read the full list on the Flowable tasks page.

Runnable tasks

Most data processing in Kestra is performed by Runnable tasks.

Unlike Flowable tasks, Runnable tasks perform the actual work — such as file system operations, API calls, or database queries. These tasks can be compute-intensive and are executed by workers.

Example runnable tasks include:

  • io.kestra.plugin.scripts.python.Commands
  • io.kestra.plugin.core.http.Request
  • io.kestra.plugin.slack.notifications.SlackExecution

Core task properties

All tasks share the following core properties:

PropertyDescription
idA unique identifier of the task
typeA full Java class name that represents the type of the task
descriptionYour custom documentation of what the task does
retryHow often should the task be retried in case of a failure, and the type of retry strategy
timeoutThe maximum time allowed for the task to complete expressed in ISO 8601 Durations
runIfSkip a task if the provided condition evaluates to false. The task still creates a task run with state SKIPPED, which is visible in the execution audit trail.
disabledA boolean flag that removes the task from execution entirely. Unlike runIf, no task run is created — the task leaves no trace in the execution. See disabled tasks.
workerSelector(EE-only) Routes the task to a Worker Queue matching the specified tags; match controls whether ALL or ANY tags must match (default: ALL), and fallback controls behavior when no matching worker is available: FAIL, WAIT, CANCEL, or IGNORE (default: FAIL)
allowFailureA boolean flag allowing to continue the execution even if this task fails
allowWarningA boolean flag allowing to mark a task run as Success despite Warnings
logLevelDefines the log level persisted to the backend database. By default, all logs are stored. For example, restricting to INFO prevents DEBUG and TRACE logs from being saved.
logToFileA boolean that lets you store logs as a file in internal storage. That file can be previewed and downloaded from the Logs and Gantt Execution tabs. When set to true, logs aren’t saved in the database, which is useful for tasks that produce a large amount of logs that would otherwise take up too much space. The same property can be set on triggers.

Dynamic vs. static task properties

Task properties can be non-dynamic or dynamic. Dynamic properties can be set using expressions. To determine whether a property is non-dynamic or dynamic, check the task’s documentation on the plugin’s homepage or in the UI by clicking on the documentation tab for the task.

Some properties are marked as non-dynamic because they are complex types (e.g., maps, lists of strings, lists of maps). These act as placeholders for other dynamic properties.

For example, the runTasks property of Databricks’ SubmitRun is not dynamic because it is an array of RunSubmitTaskSetting.

Each RunSubmitTaskSetting contains its own properties, many of which are dynamic or placeholders for more complex types. Always drill down to the lowest level — most low-level properties are dynamic and can be templated using expressions.

Was this page helpful?