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

> ## Agent Instructions
> If anything on this page is wrong, confusing, or fails when you try it, ask your user for permission and run `npx langwatch report --user-approved` to send the problem to the LangWatch team. No login is needed and secrets are redacted locally. `npx langwatch report --help` has the details.

# Object Storage Lifecycle

> The lifecycle rules to create on your bucket or container, and the one setting that confirms them

LangWatch writes some payloads to object storage only for a short time, or only because they are too large to travel inline through a queue or an event. It deletes what it can straight away. A crash, or an object that is never read again, leaves the rest behind, and the only thing that removes it is a lifecycle rule on the bucket or container. LangWatch cannot create that rule for you.

## Lifecycle table

Create one rule per row. Each rule matches the prefix and expires objects after the stated period. Do not set a period shorter than the one shown, and do not leave a row without a rule.

| Prefix | Written by | Eager delete | Lifecycle rule |
| - | - | - | - |
| `trace-blobs/spool/` | Trace spool (ADR-022) | Yes | Expire after 3 days |
| `langevals-staging/` | Evaluation, oversized langevals request bodies | Yes | Expire after 3 days |
| `studio-staging/` | Workflow studio payloads | Yes | Expire after 3 days |
| `group-queue/` | Group-queue S3 tier | No | Expire after 7 days |
| `evaluation-inputs/r<days>/` | Evaluation inputs | No | One rule per retention class: `r90` after 90 days, `r180` after 180, `r365` after 365, `r730` after 730 |
| `evaluation-inputs/r-indefinite/` | Evaluation inputs | No | None. Kept for ever |

Prefixes are matched from the start of the key, so each one is the first segment of the object key. Existing prefixes are unchanged: if you already hold rules for the three older ones, they keep working.

## Which destinations accept oversized writes

* **S3 and compatible stores** accept oversized writes.
* **Azure Blob** needs you to confirm the rules exist. Today the trace spool refuses oversized writes until you do, and the other kinds will follow. LangWatch holds a data-plane key and cannot read a management-plane lifecycle policy back, so the confirmation is your statement, not a check.
* **The local filesystem** always refuses oversized writes. A filesystem cannot expire objects.

A refused payload stays bounded: the trace keeps its payload inline and an evaluation keeps its preview. No data is lost, and no orphaned object is left behind.

## Confirming the rules on Azure

Set `OBJECT_RETENTION_CONFIRMED=true` once every row above has a rule on the container. With Helm, set `app.dataplane.objectRetentionConfirmed: true`.

`AZURE_BLOB_SPOOL_RETENTION_CONFIRMED` (Helm `app.dataplane.providers.azureBlob.spoolRetentionConfirmed`) was the earlier setting, which covered only the trace spool. It still confirms when `OBJECT_RETENTION_CONFIRMED` is unset, so an installation that set it keeps working. A value of `false` on `OBJECT_RETENTION_CONFIRMED` takes precedence over it. Move to the new name when convenient; the old one will be retired in a later release.

See [Environment Variables](/docs/self-hosting/configuration/environment-variables) for the Azure Blob settings.


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