# https://github.com/kestra-io/kestra Project Manual

Generated at: 2026-06-21 09:29:07 UTC

## Table of Contents

- [System Architecture & Multi-Server Topology](#page-1)
- [Flows, Tasks, Triggers & Execution Model](#page-2)
- [Frontend UI, Filters, Dashboards & Topology](#page-3)
- [Concurrency Limits, Replay & Execution Lifecycle](#page-4)

<a id='page-1'></a>

## System Architecture & Multi-Server Topology

### Related Pages

Related topics: [Flows, Tasks, Triggers & Execution Model](#page-2), [Concurrency Limits, Replay & Execution Lifecycle](#page-4)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [cli/src/main/java/io/kestra/cli/commands/servers/ServerCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/servers/ServerCommand.java)
- [cli/src/main/java/io/kestra/cli/commands/servers/AbstractServerCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/servers/AbstractServerCommand.java)
- [cli/src/main/java/io/kestra/cli/commands/servers/ServerCommandInterface.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/servers/ServerCommandInterface.java)
- [cli/src/main/java/io/kestra/cli/commands/sys/SysCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/sys/SysCommand.java)
- [cli/src/main/java/io/kestra/cli/services/DefaultStartupHook.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/services/DefaultStartupHook.java)
- [cli/src/main/java/io/kestra/cli/AbstractCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/AbstractCommand.java)
- [jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java)
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java)
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java)
- [charts/kestra/README.md](https://github.com/kestra-io/kestra/blob/main/charts/kestra/README.md)
</details>

# System Architecture & Multi-Server Topology

## Overview

Kestra is built as a distributed orchestration platform in which a single binary can be started in several **roles** depending on operator needs. The CLI is partitioned into a `server` command (production / scaled deployments) and a `sys` command (maintenance operations), and each role is implemented as a subcommand registered on the parent dispatcher.

The dispatcher itself lists every long-running role that the binary may take on. In [ServerCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/servers/ServerCommand.java) the `subcommands` array enumerates the full set of server types: `Executor`, `Indexer`, `Scheduler`, `StandAlone`, `WebServer`, `Worker`, `Controller`, and `Local`. A marker interface, [ServerCommandInterface.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/servers/ServerCommandInterface.java), lets framework code distinguish these server commands from ordinary CLI utilities.

This design enables three principal deployment topologies:
- **Standalone / Local** — a single process running every role for development or small workloads.
- **Split roles** — separate processes for Web, Executor, Scheduler, Worker, Controller, and Indexer (typically containerized; see the [charts/kestra README](https://github.com/kestra-io/kestra/blob/main/charts/kestra/README.md)).
- **Maintenance-only invocations** — ad-hoc `sys` tasks such as reindexing or queue draining.

## Server Roles

Each role binds to a configurable HTTP port (the `--port` option exposed by [AbstractServerCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/servers/AbstractServerCommand.java)) and shares the same Micronaut context, so configuration is loaded uniformly across nodes.

| Role | Primary responsibility |
|---|---|
| WebServer | HTTP API and static UI |
| Executor | Drives flow state machines and task scheduling |
| Worker | Executes individual task runnables |
| Scheduler | Triggers cron / schedule-based flow starts |
| Indexer | Builds and maintains searchable indexes |
| Controller | Cluster coordination and topology events |
| StandAlone | Bundles all of the above in a single JVM |
| Local | Embedded mode used by tests and the IDE |

A graceful shutdown hook is registered by `AbstractServerCommand#call`, which delegates to `KestraContext.getContext().shutdown()` ([AbstractServerCommand.java:21-26](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/servers/AbstractServerCommand.java)).

## Cluster Architecture

```mermaid
flowchart LR
    Client[UI / API Client]
    subgraph Cluster["Kestra Cluster"]
      WS[WebServer]
      EX[Executor]
      SCH[Scheduler]
      IDX[Indexer]
      CT[Controller]
      W1[Worker 1]
      W2[Worker N]
    end
    JDBC[(JDBC Storage\nH2 / MySQL / Postgres)]
    Queue[(JDBC Queue)]
    Client <--> WS
    WS --> JDBC
    EX --> JDBC
    EX --> Queue
    SCH --> JDBC
    IDX --> JDBC
    CT --> JDBC
    W1 --> Queue
    W2 --> Queue
    Queue --> EX
```

The Executors place work on the JDBC queue; the Workers consume it. Both the queue and the state records live in the relational database selected at build time. This architecture is what makes the recent *“keep JDBC queue consumer alive on transient DB errors”* fixes ([v1.3.23](https://github.com/kestra-io/kestra/releases/tag/v1.3.23), [v1.2.22](https://github.com/kestra-io/kestra/releases/tag/v1.2.22), [v1.0.47](https://github.com/kestra-io/kestra/releases/tag/v1.0.47)) so critical — a single transient DB hiccup can otherwise strand in-flight tasks across every Worker.

## Storage Abstraction (Multi-Database)

Kestra ships per-database modules that share a JDBC base. The dashboard repository, for instance, is implemented separately for each engine:

- [H2DashboardRepository](https://github.com/kestra-io/kestra/blob/main/jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java) — `@H2RepositoryEnabled` for embedded / dev.
- [MysqlDashboardRepository](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java) — `@MysqlRepositoryEnabled` for production clusters.

Both extend `AbstractJdbcDashboardRepository` and inject a `@Named("dashboards") MysqlRepository<Dashboard>` (or H2 equivalent) plus an `ApplicationEventPublisher<CrudEvent<Dashboard>>` and a list of `QueryBuilderInterface` instances. The dialect-specific piece is isolated to `findCondition(query)`, returning a jOOQ `Condition` for that engine.

A second example, [MysqlFlowTopologyRepository](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java), overrides `buildMergeStatement` to emit a dialect-correct `INSERT ... ON DUPLICATE KEY UPDATE` upsert — Postgres would use `ON CONFLICT (...) DO UPDATE` in its sibling module. This pattern keeps engine-specific SQL confined to thin overrides while sharing schema and lifecycle code.

## Startup, Configuration, and Maintenance

A `DefaultStartupHook` ([DefaultStartupHook.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/services/DefaultStartupHook.java)) runs only for full server commands (any `ServerCommandInterface` *except* `WorkerCommand`), and is responsible for:

- Saving the running Kestra version via `VersionService::maybeSaveOrUpdateInstanceVersion`.
- Creating a default MCP server entry per tenant (`McpServerService`).
- Recording the active edition (OSS / EE) through `EditionProvider`.

The base [AbstractCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/AbstractCommand.java) loads a YAML configuration file when one is supplied via `--config`, contributing additional `Map<String, Object>` properties into the Micronaut context. Recent CLI work ([v1.3.23](https://github.com/kestra-io/kestra/releases/tag/v1.3.23)) explicitly restored this behavior so `--config` works correctly when placed before the subcommand.

System-level maintenance is exposed through [SysCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/sys/SysCommand.java), whose two subcommands are:

- `ReindexCommand` — rebuilds search indexes (used after major data migrations).
- `SubmitQueuedCommand` — re-submits executions left stuck in the queue, addressing the cluster failure mode described in the JDBC queue consumer fixes above.

## Helm / Kubernetes Deployment

Production clusters typically deploy each role as its own Deployment or StatefulSet. The Helm chart (see [charts/kestra/README.md](https://github.com/kestra-io/kestra/blob/main/charts/kestra/README.md)) exposes knobs including `common.replicas`, `common.kind` (Deployment vs StatefulSet), liveness/readiness probes pointing at `/health/liveness`, `/health/readiness`, and `/health`, and resource/affinity overrides so that heavier roles (Executor, Worker) can be scaled independently of the WebServer.

## See Also

- [CLI Commands & Server Roles](./cli-commands.md)
- [JDBC Storage Backends](./jdbc-storage.md)
- [Scheduler & Triggers](./scheduler-triggers.md)
- [Helm Chart Reference](./helm-chart.md)

---

<a id='page-2'></a>

## Flows, Tasks, Triggers & Execution Model

### Related Pages

Related topics: [System Architecture & Multi-Server Topology](#page-1), [Concurrency Limits, Replay & Execution Lifecycle](#page-4)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [README.md](https://github.com/kestra-io/kestra/blob/develop/README.md)
- [cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java](https://github.com/kestra-io/kestra/blob/develop/cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java)
- [jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java)
- [jdbc-h2/src/main/java/io/kestra/repository/h2/H2LogRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2LogRepository.java)
- [jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java)
- [jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java)
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlExecutionRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlExecutionRepository.java)
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java)
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java)
- [jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresFlowTopologyRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresFlowTopologyRepository.java)
- [ui/packages/design-system/package.json](https://github.com/kestra-io/kestra/blob/develop/ui/packages/design-system/package.json)
</details>

# Flows, Tasks, Triggers & Execution Model

## Overview

Kestra is an open-source, event-driven orchestration platform that unifies scheduled and event-driven automation behind a declarative YAML interface. According to the project README, the four foundational concepts are:

- **Flows** — the core unit in Kestra, representing a workflow composed of tasks.
- **Tasks** — individual units of work, such as running a script, moving data, or calling an API.
- **Triggers** — schedules or events that initiate the execution of flows.
- **Executions** — the runtime instance of a flow, persisted with its task states, logs, and outputs.

Source: [README.md](https://github.com/kestra-io/kestra/blob/develop/README.md)

The platform treats workflow orchestration as code, so the YAML definition of a Flow is the canonical source of truth — even when the workflow is built or modified from the UI, via the API, or through CI/CD, the source-of-truth YAML stays in sync.

## Core Domain Model

The persistence layer reveals the typed domain entities that make up the execution model. Each entity has a dedicated JDBC repository implementation, following the same pattern across H2, MySQL, and Postgres backends:

| Entity | Java Class | Repository (H2 example) |
|--------|-----------|--------------------------|
| Flow | `io.kestra.core.models.flows.Flow` | `H2ExecutionRepository` reuses flow context |
| Execution | `io.kestra.core.models.executions.Execution` | `H2ExecutionRepository` |
| Trigger state | `io.kestra.core.scheduler.model.TriggerState` | `H2TriggerRepository` |
| Log entry | `io.kestra.core.models.executions.LogEntry` | `H2LogRepository` |
| Dashboard | `io.kestra.core.models.dashboards.Dashboard` | `H2DashboardRepository` |
| Flow topology | `io.kestra.core.models.topologies.FlowTopology` | (Postgres/MySQL specific) |

Source: [jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java), [jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java), [jdbc-h2/src/main/java/io/kestra/repository/h2/H2LogRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2LogRepository.java), [jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java)

The JDBC repositories all extend shared abstract bases (e.g., `AbstractJdbcExecutionRepository`) injected with the appropriate `JdbcFilterService`, jOOQ `DSLContext`, and a `CrudEvent` publisher — confirming the model is fully event-driven.

## Flow → Execution Lifecycle

```mermaid
flowchart LR
    A[YAML Flow Source] --> B[FlowRepositoryInterface.find]
    B --> C[Flow loaded into runtime]
    C --> D{Trigger fires?}
    D -- Schedule --> E[Execution created]
    D -- Event --> E
    D -- Manual/API --> E
    E --> F[TaskRunner executes tasks]
    F --> G[Execution state persisted]
    G --> H[LogEntry recorded]
    G --> I[FlowTopology updated]
```

The CLI's `ReindexCommand` illustrates the write side of the Flow lifecycle. It loads every flow across all tenants via `FlowRepositoryInterface.findAllForAllTenants()`, then calls `FlowService.update(...)` with the latest source so the index and topology stay consistent with the YAML.

Source: [cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java](https://github.com/kestra-io/kestra/blob/develop/cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java)

`FlowTopology` is maintained as a derived view of the flow graph. Both MySQL and Postgres implementations extend `AbstractJdbcFlowTopologyRepository`, overriding the merge-statement syntax for their respective dialect (MySQL's `onDuplicateKeyUpdate` vs. Postgres's `onConflict().doUpdate()`).

Source: [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java), [jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresFlowTopologyRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresFlowTopologyRepository.java)

## Triggers, Scheduling & State Recovery

Triggers are modeled as `TriggerState` rows, written and read by `H2TriggerRepository` (and its MySQL/Postgres counterparts). The `AbstractJdbcTriggerRepository` base class encapsulates the scheduling and recovery logic. Recent changelogs confirm the scheduler's behavior under re-enable scenarios:

- v1.2.22 (scheduler): "prevent recovering missed schedules when re-enabling a trigger via API (#16721)". This means that when an admin re-enables a trigger that had been disabled, the scheduler does **not** retroactively replay the schedules it would have produced while it was paused — by design.

Source: [jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java)

## Community Discussion & Known Gaps

Several open community issues map directly to this execution model:

- **Concurrency limits** ([#1400](https://github.com/kestra-io/kestra/issues/1400)) — A long-standing feature request (8 comments) asking for the ability to cap concurrent executions per flow with two policies: *queue excess* or *cancel excess*. The `io.kestra.core.models.flows.Concurrency` class is part of the same package as Flow, indicating where such a policy would live.
- **Bulk replay on Flow's Executions tab** ([#16906](https://github.com/kestra-io/kestra/issues/16906)) — The backend endpoint already exists, but a UI button for selecting multiple executions and replaying them in bulk is missing. This is a UI gap over an already-shipped API capability.
- **Dashboard quick-filter "All" tab empty** ([#16812](https://github.com/kestra-io/kestra/issues/16812)) — On the dashboard executions widget, the **All** filter sometimes shows "no results" while state-specific tabs (e.g., Success, Failed) return rows. Points to a filter aggregation bug in `H2DashboardRepository`-style queries.
- **Filters EPIC** ([#15952](https://github.com/kestra-io/kestra/issues/15952)) — Collecting all backend changes needed to support richer conditional filters; the `JdbcFilterService` injected into each repository is the consolidation point.
- **Outdated revision warning** (v1.0.46, #16570) — When the UI restored this warning, it implicitly requires that each `Flow` row carry a revision/version that can be compared before save — confirming versioning is part of the Flow model.

## Putting It Together

The execution model in Kestra can be summarized as four tightly-coupled layers:

1. **Authoring layer** — Flow YAML stored via `FlowRepositoryInterface`, validated and indexed.
2. **Triggering layer** — `TriggerState` rows observed by the scheduler; each fire creates an `Execution`.
3. **Runtime layer** — `Execution` rows progress through task states; `LogEntry` rows stream events; `FlowTopology` is recomputed from the current flow source.
4. **Observation layer** — `Dashboard` widgets query the JDBC repositories using `JdbcFilterService`-built conditions and `CrudEvent`-published changes.

Because every layer is a normal JDBC repository with explicit `CrudEvent` publication, downstream consumers (notifications, audit, plugins) can subscribe to changes uniformly across H2, MySQL, and Postgres — which is why the same `AbstractJdbc*` base is reused in each backend module.

Source: [README.md](https://github.com/kestra-io/kestra/blob/develop/README.md), [jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java), [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlExecutionRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlExecutionRepository.java), [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java](https://github.com/kestra-io/kestra/blob/develop/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java)

## See Also

- [Plugin Ecosystem](https://kestra.io/plugins) — Hundreds of task and trigger plugins built on the same execution model.
- [Plugin Developer Guide](https://kestra.io/docs/plugin-developer-guide/) — How to add a new `Task` or `Trigger` type that plugs into `Execution`.
- [Terraform Provider](https://kestra.io/docs/terraform/) — Manage Flow resources as Infrastructure-as-Code.
- Issue [#15952 — Filters EPIC](https://github.com/kestra-io/kestra/issues/15952) — Ongoing work that will refine how `Execution` queries are filtered across the JDBC repositories.

---

<a id='page-3'></a>

## Frontend UI, Filters, Dashboards & Topology

### Related Pages

Related topics: [Flows, Tasks, Triggers & Execution Model](#page-2), [Concurrency Limits, Replay & Execution Lifecycle](#page-4)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [README.md](https://github.com/kestra-io/kestra/blob/main/README.md)
- [ui/package.json](https://github.com/kestra-io/kestra/blob/main/ui/package.json)
- [ui/packages/design-system/package.json](https://github.com/kestra-io/kestra/blob/main/ui/packages/design-system/package.json)
- [ui/packages/topology/package.json](https://github.com/kestra-io/kestra/blob/main/ui/packages/topology/package.json)
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java)
- [jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java)
- [jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresDashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresDashboardRepository.java)
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java)
- [charts/kestra/README.md](https://github.com/kestra-io/kestra/blob/main/charts/kestra/README.md)
</details>

# Frontend UI, Filters, Dashboards & Topology

## Overview

The Kestra frontend is a Vue 3 + Vite single-page application shipped from the `ui/` workspace. It is the primary surface where users author flows as YAML, observe executions, build dashboards, and visualize workflow graphs. The frontend is composed of several internal packages that are published individually so that the design system and the topology graph can be reused by the EE distribution and third-party plugins.

The application bootstraps from [ui/src/main.ts](https://github.com/kestra-io/kestra/blob/main/ui/src/main.ts) and is composed of routed views for flows, executions, dashboards, logs, and admin features. The UI communicates with the backend through REST endpoints exposed by the JDBC repositories. A release ships as a static bundle that can be served from the same JVM process as the orchestration engine or from a CDN.

The product positioning from [README.md](https://github.com/kestra-io/kestra/blob/main/README.md) is "Everything as Code and from the UI": flows are stored as YAML in version control, but the editor, the drag-and-drop topology builder, and the live validation are the primary authoring tools. This dual model is what makes filters, dashboards, and topology tightly coupled in the user experience.

## UI Architecture and Design System

The UI is split into a root app and reusable libraries. The root [ui/package.json](https://github.com/kestra-io/kestra/blob/main/ui/package.json) declares Vue 3.5, Vite 8, Vitest 4, Storybook 10, vue-echarts, vue-i18n, and vue-router as direct dependencies. The Storybook setup is used for component-level visual regression.

Two internal libraries are exposed via npm `exports`:

- `@kestra-io/design-system` — defined in [ui/packages/design-system/package.json](https://github.com/kestra-io/kestra/blob/main/ui/packages/design-system/package.json), this package wraps Element Plus primitives with Kestra styling and a11y tests via `@storybook/addon-a11y`.
- `@kestra-io/topology` — defined in [ui/packages/topology/package.json](https://github.com/kestra-io/kestra/blob/main/ui/packages/topology/package.json), this package is "powered by Vue Flow" and exports both the default surface and a `vue-flow-utils` entrypoint for helper functions.

| Package | Role | Key dependency |
|---|---|---|
| `ui` (root) | Application shell, routes, plugins | Vue 3.5, Vite 8, vue-echarts |
| `@kestra-io/design-system` | Reusable component library | Element Plus, Storybook, vue-tsc |
| `@kestra-io/topology` | DAG visualization for flows | Vue Flow |

Source: [ui/package.json](https://github.com/kestra-io/kestra/blob/main/ui/package.json) and [ui/packages/design-system/package.json](https://github.com/kestra-io/kestra/blob/main/ui/packages/design-system/package.json).

## Filters

The Executions view uses a composite filter model: a **quick interval selector** for the time window (15m / 1h / ...) and **conditional groups** for advanced predicates joined by `AND` / `OR`. Both pieces live in the same page, but the contract between them has been a recurring source of community reports.

Issue [#16433](https://github.com/kestra-io/kestra/issues/16433) "Quick interval selector doesn't fit conditional groups" reports that the time selector does not interact correctly with conditional groups: when a user adds an `OR` group with two distinct predicates, the interval selector scopes the wrong subset of the result set. Issue [#15952](https://github.com/kestra-io/kestra/issues/15952) is the umbrella epic "Filters, backend changes needed for filter" and tracks the broader rewrite that the frontend has been aligned against.

The complementary feature request #16906 — "Add bulk-replay on Flow's Executions tab" — depends on the same filter model: bulk actions are computed on whatever the active filter returned, and the UI button is what is currently missing on the `main` branch (already merged on `develop`).

## Dashboards

Dashboards are a first-class persistence model in Kestra. The backend defines a `Dashboard` JOOQ-backed entity and a `DashboardRepository` abstraction that is implemented per database. The three concrete implementations are:

- [jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java) — embedded/test storage.
- [jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresDashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresDashboardRepository.java) — production storage.
- [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java) — alternative production storage.

Each implementation extends `AbstractJdbcDashboardRepository` and overrides `findCondition(String query)` to translate a free-text query into a JOOQ `Condition` specific to the dialect (H2, Postgres, or MySQL). All three are annotated with `@RepositoryBean` and a per-dialect `@MysqlRepositoryEnabled` / `@H2RepositoryEnabled` / `@PostgresRepositoryEnabled` stereotype so that the right bean is wired at startup. The `eventPublisher` parameter publishes `CrudEvent<Dashboard>` for downstream cache invalidation, and a list of `QueryBuilderInterface<?>` beans is injected so that dashboard queries can be extended by plugins.

On the frontend, the Executions quick-filter rendered inside dashboard widgets is the bar **All / Running / Paused / Success / Warning / Failed**. Issue [#16812](https://github.com/kestra-io/kestra/issues/16812) "Dashboard 'Executions' quick-filter: the 'All' tab is empty while state tabs show executions" reports that the **All** tab returns zero rows even when state-specific tabs return many, which is a sign that the default branch in the widget does not strip the implicit `state` predicate the way the state-specific tabs do.

A related community request is issue [#16603](https://github.com/kestra-io/kestra/issues/16603) "Logs chart: drag-to-select time-range brush", which asks for a Grafana-style drag interaction on the timeseries chart above the global `/logs` page so users can filter the list to the brushed window — the same interaction model would naturally extend to dashboard timeseries panels.

## Topology and Auto-Completion

The Topology view is described in [README.md](https://github.com/kestra-io/kestra/blob/main/README.md) as a "Live Topology View" that "shows your workflow as a Directed Acyclic Graph (DAG) that updates in real-time" alongside a "Drag-and-Drop Interface" and "Real-Time Validation". The visual rendering is implemented by the `@kestra-io/topology` package, which wraps the Vue Flow library. Its `package.json` (`sideEffects` includes `./dist/style.css`) confirms the graph ships with its own stylesheet so it can be embedded in other surfaces (e.g. a dashboard panel, or the EE namespace explorer).

The DAG is persisted in the `flowtopologies` table by `AbstractJdbcFlowTopologyRepository`. The MySQL implementation in [jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java](https://github.com/kestra-io/kestra/blob/main/jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java) overrides `buildMergeStatement` to issue an `INSERT ... ON DUPLICATE KEY UPDATE` (a MySQL-specific upsert) rather than the Postgres `MERGE` statement, so that the topology graph is regenerated as the YAML changes without a separate read-modify-write cycle.

Auto-completion is a long-standing community request tracked in issue [#3331](https://github.com/kestra-io/kestra/issues/3331) "Add Inputs, Outputs, Trigger and Variables autocompletion", which calls for in-editor suggestions for `{{ inputs.* }}`, `{{ outputs.* }}`, `{{ trigger.* }}`, and `{{ variables.* }}`. The same feature is also relevant to the proposed flow-template customization in issue [#4956](https://github.com/kestra-io/kestra/issues/4956), where a configuration-level template would feed the autocomplete dictionary.

## Operational Notes and Common Failure Modes

- **JDBC queue consumer resilience**: a regression that caused the queue consumer to die on transient DB errors was fixed in v1.0.47, v1.2.22, and v1.3.23 (see release notes for [#16794](https://github.com/kestra-io/kestra/issues/16794), [#16814](https://github.com/kestra-io/kestra/issues/16814), [#16816](https://github.com/kestra-io/kestra/issues/16816)). Operators on older versions should monitor the worker logs for unhandled JDBC exceptions.
- **Outdated revision warning**: the UI used to silently overwrite edits made on stale revisions; the "outdated revision warning and save confirmation" was restored in v1.0.46 (release `318fa96`).
- **Helm chart migration**: the chart in [charts/kestra/README.md](https://github.com/kestra-io/kestra/blob/main/charts/kestra/README.md) flags breaking changes between 0.x.x and 1.0.0 — notably `image.image` → `image.repository` and `serviceAccountName` → `serviceAccount.{create,automount,annotations,name}`. Read the chart README before upgrading production clusters.
- **PostHog in dev mode**: v1.0.47 disabled PostHog in dev mode to stop the survey request spam on redirects ([#16745](https://github.com/kestra-io/kestra/issues/16745)).

## See Also

- Filters epic [#15952](https://github.com/kestra-io/kestra/issues/15952)
- Dashboard quick-filter bug [#16812](https://github.com/kestra-io/kestra/issues/16812)
- Quick interval selector + conditional groups [#16433](https://github.com/kestra-io/kestra/issues/16433)
- Bulk-replay on Executions tab [#16906](https://github.com/kestra-io/kestra/issues/16906)
- Logs chart time-range brush [#16603](https://github.com/kestra-io/kestra/issues/16603)
- Auto-completion for inputs/outputs/triggers/variables [#3331](https://github.com/kestra-io/kestra/issues/3331)
- Flow template customization [#4956](https://github.com/kestra-io/kestra/issues/4956)

---

<a id='page-4'></a>

## Concurrency Limits, Replay & Execution Lifecycle

### Related Pages

Related topics: [System Architecture & Multi-Server Topology](#page-1), [Flows, Tasks, Triggers & Execution Model](#page-2), [Frontend UI, Filters, Dashboards & Topology](#page-3)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [core/src/main/java/io/kestra/core/models/flows/Concurrency.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/flows/Concurrency.java)
- [core/src/main/java/io/kestra/core/models/executions/Execution.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/executions/Execution.java)
- [core/src/main/java/io/kestra/core/models/executions/ExecutionKilled.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/executions/ExecutionKilled.java)
- [core/src/main/java/io/kestra/core/models/executions/ExecutionQueued.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/executions/ExecutionQueued.java)
- [core/src/main/java/io/kestra/core/executor/command/Replay.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/executor/command/Replay.java)
- [core/src/main/java/io/kestra/core/executor/command/Restart.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/executor/command/Restart.java)
- [cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java)
- [cli/src/main/resources/application.yml](https://github.com/kestra-io/kestra/blob/main/cli/src/main/resources/application.yml)
- [README.md](https://github.com/kestra-io/kestra/blob/main/README.md)
</details>

# Concurrency Limits, Replay & Execution Lifecycle

Kestra is a declarative, event-driven orchestration platform that models workflows as **Flows** composed of **Tasks**. Three concerns dominate the runtime behavior of those flows: how many executions of a given flow may run at once, how to reproduce or repair an existing execution after the fact, and the set of states an execution transitions through from creation to termination. This page documents those three concerns together because they share the same core types and operator-facing commands. Source: [README.md](https://github.com/kestra-io/kestra/blob/main/README.md)

## 1. Concurrency Limits

A flow author can attach a `concurrency` block to a flow to cap how many of its executions are allowed to be in a non-terminal state at the same time. The model is defined in [Concurrency.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/flows/Concurrency.java) and is referenced by the `Execution` aggregate in [Execution.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/executions/Execution.java). The community has long requested first-class concurrency controls — see issue [#1400 "Concurrency limits: limit concurrent executions"](https://github.com/kestra-io/kestra/issues/1400), which describes the two competing semantics operators want:

| Behavior   | Description                                                                                                  | When to choose                                                                                  |
|------------|--------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|
| `QUEUE`    | Excess executions are held in a queued state and dispatched in order as slots free up.                       | Backpressure-friendly workloads where every trigger must eventually run.                         |
| `CANCEL`   | Excess executions are rejected (killed) when the threshold is reached.                                       | Strict SLA scenarios where only the most recent N runs matter.                                  |

When a flow defines `concurrency` and the cap is reached, the new execution is represented as an `ExecutionQueued` event ([ExecutionQueued.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/executions/ExecutionQueued.java)) rather than entering the running state. Conversely, when an execution must be forcibly removed because of concurrency, a `KILLED` state is recorded via the `ExecutionKilled` event ([ExecutionKilled.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/executions/ExecutionKilled.java)).

## 2. Replay and Restart

Two related commands operate on past executions:

- **Replay** ([Replay.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/executor/command/Replay.java)) creates a brand-new execution of the flow. The new execution is a sibling of the original, sharing inputs/parameters but with fresh timing, state, and identifiers. Replay is appropriate when an operator wants to re-run a flow with the same configuration after a code or data fix.
- **Restart** ([Restart.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/executor/command/Restart.java)) re-enters an existing execution from a chosen task, preserving prior outputs of upstream tasks so they are not recomputed. Restart is appropriate for repairing a single failed task run.

Both are exposed via the Executor API and surfaced in the UI on a Flow's Executions tab. Community demand for a **bulk** replay action is tracked in issue [#16906 "Add bulk-replay on Flow's Executions tab"](https://github.com/kestra-io/kestra/issues/16906), which notes that the underlying endpoint already exists and only the UI affordance is missing.

A related maintenance command is the CLI's `reindex` ([ReindexCommand.java](https://github.com/kestra-io/kestra/blob/main/cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java)), which "reindex all records of a type: read them from the database then update them." It currently supports only the `flow` type and iterates `findAllForAllTenants()` before re-saving each flow through `FlowService`. This is useful when the on-disk serialization of flows has changed and existing rows need to be re-written.

## 3. Execution Lifecycle

Every execution is a finite state machine keyed on the `state` field of [Execution.java](https://github.com/kestra-io/kestra/blob/main/core/src/main/java/io/kestra/core/models/executions/Execution.java). The terminal states — `SUCCESS`, `WARNING`, `FAILED`, `KILLED` — are visible in the dashboard's quick-filter tabs (see issue [#16812](https://github.com/kestra-io/kestra/issues/16812) about the `All / Running / Paused / Success / Warning / Failed` tab bar on dashboard executions widgets). The non-terminal states are `CREATED`, `RUNNING`, `PAUSED`, and `QUEUED`.

```mermaid
stateDiagram-v2
    [*] --> CREATED
    CREATED --> QUEUED: concurrency limit reached
    CREATED --> RUNNING: slot available
    QUEUED --> RUNNING: slot available
    RUNNING --> PAUSED: pause command
    PAUSED --> RUNNING: resume command
    RUNNING --> SUCCESS
    RUNNING --> WARNING
    RUNNING --> FAILED
    RUNNING --> KILLED: kill / concurrency cancel
    SUCCESS --> [*]
    WARNING --> [*]
    FAILED --> [*]: restart
    KILLED --> [*]
    FAILED --> [*]: replay
```

The `QUEUED` state is materialized by `ExecutionQueued` and the `KILLED` state by `ExecutionKilled`. JVM-level settings that influence how long executions are kept and how the JDBC queue is polled live in [application.yml](https://github.com/kestra-io/kestra/blob/main/cli/src/main/resources/application.yml) — for example `kestra.jdbc.queue.max-poll-interval` (default `500ms`), `kestra.jdbc.queue.poll-switch-interval` (default `60s`), and the `cleaner` retention rules for `LogEntry` and `MetricEntry` rows.

## 4. Common Failure Modes

- **Stale "All" tab on dashboards:** when the unified `All` quick-filter returns no rows but a state tab does, it is usually a filter/aggregation mismatch in the dashboard widget ([#16812](https://github.com/kestra-io/kestra/issues/16812)). Verify the `findCondition` and date-grouping helpers in the JDBC repository subclasses.
- **Replay creates a duplicate instead of a restart:** confirm whether the operator needs a sibling (`Replay`) or an in-place re-entry (`Restart`).
- **Queue consumer dies on transient DB errors:** addressed in 1.3.23 (`42cb301`), 1.2.22 (`31dcef8`) and 1.0.47 (`4cccc93`) — the JDBC queue consumer is now kept alive across transient errors. Operators on older versions should monitor for unexpected queue stalls.

## See Also

- Triggers & Schedules
- JDBC Repositories & Queue Internals
- Dashboard Widgets & Filters

---

<!-- evidence_pipeline_checked: true -->
<!-- evidence_injected: true -->

---

## Pitfall Log

Project: kestra-io/kestra

Summary: Found 27 structured pitfall item(s), including 2 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

## 1. Installation risk - Installation risk requires verification

- Severity: high
- Evidence strength: source_linked
- Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16896

## 2. Maintenance risk - Maintenance risk requires verification

- Severity: high
- Evidence strength: source_linked
- Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16603

## 3. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: runtime_trace
- Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Repro command: `docker run --pull=always -it -p 8080:8080 --user=root --name kestra --restart=always -v kestra_data:/app/storage -v /var/run/docker.sock:/var/run/docker.sock -v /tmp:/tmp kestra/kestra:latest server local`
- Evidence: identity.distribution | https://github.com/kestra-io/kestra

## 4. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this installation risk before relying on the project: v0.22.44
- User impact: Upgrade or migration may change expected behavior: v0.22.44
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v0.22.44

## 5. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16433

## 6. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: Allow adjusting the flow template based on configuration
- User impact: Developers may misconfigure credentials, environment, or host setup: Allow adjusting the flow template based on configuration
- Evidence: failure_mode_cluster:github_issue | https://github.com/kestra-io/kestra/issues/4956

## 7. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v1.0.46
- User impact: Upgrade or migration may change expected behavior: v1.0.46
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.0.46

## 8. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v1.3.20
- User impact: Upgrade or migration may change expected behavior: v1.3.20
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.20

## 9. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v1.3.21
- User impact: Upgrade or migration may change expected behavior: v1.3.21
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.21

## 10. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v1.3.22
- User impact: Upgrade or migration may change expected behavior: v1.3.22
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.22

## 11. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this configuration risk before relying on the project: v1.3.23
- User impact: Upgrade or migration may change expected behavior: v1.3.23
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.23

## 12. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16812

## 13. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16433

## 14. Capability evidence risk - Capability evidence risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: README/documentation is current enough for a first validation pass.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.assumptions | https://github.com/kestra-io/kestra

## 15. Runtime risk - Runtime risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this runtime risk before relying on the project: Dashboard "Executions" quick-filter: the "All" tab is empty while state tabs show executions
- User impact: Developers may hit a documented source-backed failure mode: Dashboard "Executions" quick-filter: the "All" tab is empty while state tabs show executions
- Evidence: failure_mode_cluster:github_issue | https://github.com/kestra-io/kestra/issues/16812

## 16. Maintenance risk - Maintenance risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Developers should check this migration risk before relying on the project: v1.2.22
- User impact: Upgrade or migration may change expected behavior: v1.2.22
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.2.22

## 17. Maintenance risk - Maintenance risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/kestra-io/kestra

## 18. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: downstream_validation.risk_items | https://github.com/kestra-io/kestra

## 19. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: risks.scoring_risks | https://github.com/kestra-io/kestra

## 20. Capability evidence risk - Capability evidence risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this capability risk before relying on the project: Add bulk-replay on Flow's Executions tab
- User impact: Developers may hit a documented source-backed failure mode: Add bulk-replay on Flow's Executions tab
- Evidence: failure_mode_cluster:github_issue | https://github.com/kestra-io/kestra/issues/16906

## 21. Capability evidence risk - Capability evidence risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this capability risk before relying on the project: Logs chart: drag-to-select time-range brush (Grafana/GCP/PostHog style)
- User impact: Developers may hit a documented source-backed failure mode: Logs chart: drag-to-select time-range brush (Grafana/GCP/PostHog style)
- Evidence: failure_mode_cluster:github_issue | https://github.com/kestra-io/kestra/issues/16603

## 22. Runtime risk - Runtime risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this performance risk before relying on the project: [Filters] Quick interval selector doesn't fit conditional groups
- User impact: Developers may hit a documented source-backed failure mode: [Filters] Quick interval selector doesn't fit conditional groups
- Evidence: failure_mode_cluster:github_issue | https://github.com/kestra-io/kestra/issues/16433

## 23. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: issue_or_pr_quality=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/kestra-io/kestra

## 24. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: release_recency=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/kestra-io/kestra

## 25. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this maintenance risk before relying on the project: v1.0.47
- User impact: Upgrade or migration may change expected behavior: v1.0.47
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.0.47

## 26. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this maintenance risk before relying on the project: v1.1.20
- User impact: Upgrade or migration may change expected behavior: v1.1.20
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.1.20

## 27. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: Developers should check this maintenance risk before relying on the project: v1.2.21
- User impact: Upgrade or migration may change expected behavior: v1.2.21
- Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.2.21

<!-- canonical_name: kestra-io/kestra; human_manual_source: deepwiki_human_wiki -->