Interactively purge logs, executions, and internal storage files to free up disk space

Reclaim disk space on your Kestra instance by interactively purging logs, executions, metrics, and internal storage files within a time range you control. Over time, completed executions, their logs, collected metrics, and intermediate files in internal storage accumulate and consume disk. This flow gives operators a safe, on demand way to clean up exactly the data types they choose, between a start and end date, with an explicit confirmation step that guards against accidental deletion.

How it works

The flow is launched manually and collects inputs first: a start and end DATETIME that bound the purge window, and a what_to_purge MULTISELECT where you pick any combination of LOGS, EXECUTIONS, METRICS, and STORAGE. A final allow_destructive_action STRING input uses dependsOn so it only appears once the other inputs are filled, and a validator of ^ALLOW$ forces you to type ALLOW before the flow will run.

Four tasks then execute conditionally based on your selection. purge_logs uses io.kestra.plugin.core.log.PurgeLogs to remove logs between the dates. Three tasks built on io.kestra.plugin.core.execution.PurgeExecutions handle the rest: purge_internal_storage clears stored files (purgeStorage: true), purge_metrics clears metrics (purgeMetric: true), and purge_executions removes execution records (purgeExecution: true). Each task runs only when its data type is selected, via runIf expressions like {{ inputs.what_to_purge contains 'LOGS' }}. A pluginDefaults block applies the startDate and endDate to every PurgeExecutions task so the window stays consistent.

What you get

• On demand cleanup of logs, executions, metrics, and internal storage files
• Fine grained control over which data types are purged in a single run
• A bounded time window so you never delete more than intended
• A typed ALLOW confirmation gate before any destructive action

Who it's for

• Platform and infrastructure engineers managing Kestra instances
• Operators responding to low disk space alerts
• Teams enforcing data retention policies on orchestration metadata

Why orchestrate this with Kestra

Built in retention settings run on fixed schedules and apply broadly. This flow turns cleanup into a declarative YAML workflow you can run interactively with operator chosen scope, add retries to, and track through full execution lineage so every purge is audited. You can also wire it to event triggers or schedules later, filling the gap left by static, all or nothing retention configuration.

Prerequisites

A running Kestra instance with admin access to purge logs, executions, metrics, and internal storage.

Secrets

This flow uses only core plugins and references no secrets.

Quick start

1. Add the flow to a namespace on your Kestra instance.
2. Execute it manually from the UI.
3. Set the start and end dates and select the data types in what_to_purge.
4. Type ALLOW in allow_destructive_action and run.

How to extend

• Add a schedule or event trigger to automate periodic cleanup.
• Send a notification task summarizing what was purged.
• Split into per environment flows with namespace specific defaults.

Links

• https://kestra.io/plugins/plugin-core