> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zylon.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Hard delete

> Configure the retention policy used by the workspace cleanup task

<Warning>
  **Upcoming release — Zylon 1.58**

  These 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](/en/v1.57/overview).
</Warning>

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.

```yaml theme={null}
zylonBackend:
  scheduler:
    cleanup:
      enabled: false
      cron: "0 3 * * *"
      timezone: "UTC"
      minimumIntervalMinutes: 1440
      workspace:
        enabled: true
      deleteAfterDays: 14
      logging:
        enabled: false
        deleteAfterDays: 180
```

## 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.

```yaml theme={null}
zylonBackend:
  scheduler:
    cleanup:
      enabled: true
      cron: "0 3 * * *"
      timezone: "Europe/Madrid"
      workspace:
        enabled: true
      deleteAfterDays: 365
      logging:
        enabled: true
        deleteAfterDays: 180
```

`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.

<Tip>
  We suggest setting an [IANA timezone](#timezone-values) that matches your company's timezone.
</Tip>

## Accepted values

### Cron values

Cleanup uses the same 5-part cron format as sync:

```text theme={null}
minute hour day-of-month month day-of-week
```

Use values in these ranges:

| Field | Accepted values |
| - | - |
| Minute | `0-59` or `*` |
| Hour | `0-23` or `*` |
| Day of month | `1-31` or `*` |
| Month | `1-12` or `*` |
| Day of week | `0-6` or `*` |

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](https://datetime.app/iana-timezones).

### 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.

<Warning>
  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](/en/v1.58/operator-manual/configuration/features/log-delivery-storage#configure-cleanup-for-stored-logs-only).
</Warning>

## 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](/en/v1.58/customer-support-manual/zendesk-client-manual).

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.