Skip to main content
Upcoming release — Zylon 1.58These docs are published ahead of release so you can prepare your API integrations. The release image is not yet available. For installations running 1.57, use the 1.57 documentation.
The hard delete task permanently removes items after they have first been deleted in Zylon or marked inactive. When chats, projects, files, or organizations are deleted in Zylon, they remain recoverable until the retention window expires. This cleanup configuration lets each organization align Zylon’s permanent deletion behavior with its own data retention policy.

​
Default configuration

Scheduled cleanup is disabled by default. The Helm defaults configure a daily 03:00 UTC schedule and a 14-day Workspace retention threshold, used after cleanup is enabled. Helm sets timezone: "UTC"; if the backend runtime timezone setting is omitted outside Helm, the server machine’s timezone is used. Stored log cleanup uses the same cleanup scheduler. It is disabled by default; when enabled, the default stored log retention threshold is 180 days.

​
Configuration example

Edit /etc/zylon/zylon-conf.yaml, then apply the change with sudo zylon-cli sync. Use a retention window that matches your company’s policy. Many organizations require a value much higher than the default.
enabled turns scheduled cleanup checks on or off. cron determines how often the system checks inactive items and stored logs, timezone optionally defines which timezone is used to interpret the cron expression, and workspace.enabled turns hard delete cleanup for workspace data on or off. deleteAfterDays is the number of days that must pass before an inactive item or a previously deleted item is permanently removed by the cron execution. logging.enabled turns stored log cleanup on or off, and logging.deleteAfterDays deletes stored log records older than that threshold. Helm supplies UTC by default; if the backend runtime timezone setting is omitted outside Helm, the server machine’s timezone is used.
We suggest setting an IANA timezone that matches your company’s timezone.

​
Accepted values

​
Cron values

Cleanup uses the same 5-part cron format as sync:
Use values in these ranges: Examples:
  • 0 3 * * * runs every day at 03:00
  • 15 4 * * 0 runs every Sunday at 04:15

​
Timezone values

zylonBackend.scheduler.cleanup.timezone defaults to UTC in Helm. If the backend runtime setting is omitted outside Helm, the cleanup cron runs in the server machine’s timezone. The cron must also satisfy minimumIntervalMinutes, which defaults to 1440 in Helm; a more frequent cron is rejected unless this value is reduced. When you set zylonBackend.scheduler.cleanup.timezone, use a valid IANA timezone identifier. Common examples include:
  • UTC
  • Europe/Madrid
  • America/New_York
  • America/Los_Angeles
  • Asia/Tokyo
  • Pacific/Auckland
  • Africa/Johannesburg
For a practical list of IANA timezone identifiers, see IANA Time Zones.

​
Retention values

For zylonBackend.scheduler.cleanup.deleteAfterDays, use a positive whole number of days such as 14, 30, 90, or 365, according to your retention policy. For zylonBackend.scheduler.cleanup.logging.deleteAfterDays, use a positive whole number of days. The default is 180 days, which is approximately six months.
Use positive retention windows according to your company’s policy. For stored logs, logging.deleteAfterDays: 0 does not disable deletion: it makes existing logs eligible for cleanup. To disable log cleanup, set logging.enabled: false. For log retention without Workspace hard deletion, follow Log-only cleanup.

​
Access before hard delete

Before the retention window expires, deleted data is not yet permanently removed. During that time, an operator can use the CLI migration and restore flow to recover organizations, projects, chats, or files. If you need help performing that recovery, you can also contact Customer support.

​
Execution and failure handling

The cleanup task runs on the cron schedule and checks whether inactive items and previously deleted items have passed the deleteAfterDays retention window. When they have, the system flags them for hard delete and removes them from Zylon. A cleanup run may permanently delete chats, files, projects, and organizations, together with associated cascaded data. Per-item failures are logged. The task continues with other items, and the next scheduled run retries remaining items.