Purge execution data including logs, metrics and outputs on a schedule

Kestra instances accumulate execution data over time: execution records, logs, metrics, and task outputs that pile up in storage and the backend database. Left unchecked, this growth slows down the UI, inflates storage costs, and clutters your execution history. This flow is a scheduled housekeeping routine that automatically purges execution data older than one month, reclaiming space and keeping your instance responsive without any manual cleanup.

How it works

The flow runs two dedicated maintenance tasks in sequence:

1. purge_executions (io.kestra.plugin.core.execution.PurgeExecutions) deletes execution data whose endDate is older than one month, computed dynamically with {{ now() | dateAdd(-1, 'MONTHS') }}. The states property is set to SUCCESS, so only successful executions are purged and the audit trail of failed runs is preserved. purgeLog is set to false so that log deletion is handled separately.
2. purge_logs (io.kestra.plugin.core.log.PurgeLogs) deletes logs older than the same one-month cutoff. Logs are usually the largest chunk of data, so isolating them in their own task lets you run or rerun this step independently.

A Schedule trigger (io.kestra.plugin.core.trigger.Schedule) is configured to fire daily at 0 9 * * *. It ships disabled: true so the flow does not run before you have reviewed it.

What you get

• Automatic, recurring cleanup of stale execution data
• Lower storage consumption and database bloat
• A faster, less cluttered Executions UI
• Preserved audit trail of failed executions
• Independent log purging you can rerun on its own

Who it's for

• Platform and DevOps engineers operating Kestra in production
• Administrators managing retention and storage costs
• Teams running high-volume workflows that generate large log volumes

Why orchestrate this with Kestra

Storage hygiene is itself a workflow, and Kestra treats it as one. The declarative YAML makes retention policy explicit and version controlled. The Schedule trigger runs cleanup unattended on a cron cadence, while built-in retries and execution history give you observability and lineage over the maintenance job itself, something a manual database DELETE or an external cron script cannot offer. Splitting executions and logs into separate tasks means a failure in one step does not block the other, and you can rerun a single task from the UI.

Prerequisites

• A running Kestra instance with execution history to purge
• Permissions to delete execution data on that instance

Secrets

This flow uses core maintenance tasks only and references no secrets.

Quick start

1. Add the flow to your Kestra instance.
2. Review the endDate cutoff and the states filter, then adjust to your retention policy.
3. Set the trigger disabled property to false (or remove that line) to activate the daily schedule.
4. Optionally run the flow manually once to validate the result before enabling the schedule.

How to extend

• Leave the states field empty to purge executions regardless of status.
• Change the dateAdd window (for example -7, 'DAYS' or -3, 'MONTHS') to match your retention requirements.
• Adjust the cron expression to run more or less frequently.
• Add a notification task to report how much data was purged on each run.

Note: this flow will not purge flow definitions or namespace files. Only execution-related data is removed, so your code stays safe.

Links

• PurgeExecutions task
• PurgeLogs task
• Schedule trigger