Export via Blob Storage Integration

You can create schedule exports to a Blob Storage, e.g. S3, GCS, or Azure Blob Storage, for traces, observations, enriched observations, and scores.

Those exports can run every 20 minutes, or on an hourly, daily, or weekly schedule. Navigate to your project settings and select Integrations > Blob Storage to set up a new export. Select whether you want to use S3, a S3 compatible storage, Google Cloud Storage, or Azure Blob Storage.

Start exporting via Blob Storage

To set up the export navigate to Your Project > Settings > Integrations > Blob Storage.

Fill in the settings to authenticate with your vendor, enable the integration, and press save. An initial export starts shortly after you enable the integration and then continues on the schedule you selected. The export supports Parquet (default), CSV, JSON, and JSONL file formats — see File formats. Read our blob storage documentation for more information on how to get credentials for your specific vendor.

File formats

Exports can be written as Apache Parquet, CSV, JSON, or JSONL files. New integrations default to Parquet.

• Parquet is a columnar binary format that is encoded and compressed by the storage engine and can be loaded directly by most data warehouses and query engines. Because Parquet files are already compressed, gzip compression does not apply to Parquet exports.
• CSV, JSON, and JSONL are text formats that can optionally be gzip-compressed.

Parquet observation exports do not include the per-unit model price columns (input_price, output_price, total_price). These columns snapshot model definition prices at export time and may be deprecated in the future — use cost_details and total_cost for cost data, which are included in every file type. See Notes on Parquet exports in the field reference for details.

Export source (Fast Preview)

Blob Storage integrations now include an Export Source selector. New integrations default to Enriched observations (recommended) (trace attributes are directly set on observations).

This source uses enriched observations with trace attributes and provides significantly better export performance. Scores are always included, regardless of the selected source.

Available options:

• Traces and observations (legacy)
• Traces and observations (legacy) and enriched observations
• Enriched observations (recommended)

Upgrade path for existing configurations

This migration path applies to pre-cutoff Cloud projects and self-hosted deployments. Post-cutoff Cloud projects already use Enriched observations (recommended) and cannot select legacy sources.

Existing integrations continue to use Traces and observations (legacy) until changed.

To migrate safely:

1. Switch to Traces and observations (legacy) and enriched observations.
2. Validate downstream jobs and data consumers while both sources are exported (this mode creates duplicate records by design).
3. Switch to Enriched observations (recommended) once validation is complete.

For a field-level comparison of what changes when you switch sources, see Differences between enriched and legacy exports.

For rollout details, see the Simplify for Scale changelog.

Exported fields

For a complete reference of all fields included in each export file (traces, observations, enriched observations, and scores), see the Export Field Reference.

Choose which columns are exported

Field groups let you choose which column groups appear in each row of the observation exports. They apply to observation exports for all export sources — both the enriched observations_v2 file and the legacy observations file — with different column content depending on the source. Eleven groups cover the full row, ten of which are toggleable; toggle them in Project Settings → Integrations → Blob Storage under Export Field Groups.

Groups are listed in the order they appear in the UI; fields within each group are sorted alphabetically. The core group is required and always exported.

New integrations default to all eleven groups, so behavior matches earlier exports unless you narrow the selection. Field groups apply to observation exports only — the legacy traces file always contains a fixed column set.

Configure via REST API

GET and PUT /api/public/integrations/blob-storage accept and return:

• exportSource — LEGACY_TRACES_OBSERVATIONS, OBSERVATIONS_V2, or LEGACY_TRACES_AND_ENRICHED_OBSERVATIONS.
• exportFieldGroups — a list of group names. Must include core when provided. Applies to observation exports for all export sources. When omitted on update, the existing value is preserved.
• fileType — PARQUET (default for new integrations), CSV, JSON, or JSONL.
• compressed — boolean; defaults to true for new integrations. When true, files are written as .csv.gz, .json.gz, or .jsonl.gz. Does not apply to PARQUET — Parquet files are compressed by the storage engine and always written as plain .parquet files.

See the API reference for the full schema.

Export modes

The Export Mode determines how far back the integration starts exporting from:

Changing the mode resets the sync position, so it's also the mechanism for re-scanning history — see Re-exporting data and configuration changes.

How exports run

Each run exports one time window of data to your bucket, then advances and exports the next window on your configured schedule.

• Export delay. Data is exported with a short delay rather than right up to the current moment, so records still moving through ingestion are not exported half-written. Expect a brief lag between when an event is recorded and when it appears in your bucket.
• Catch-up / backfill. When an integration starts from a historic point — or falls behind — it works forward through the backlog and may write many files in quick succession before settling into its normal cadence. A freshly created full-history integration does this until it catches up to the present.

Export status

The integration settings page shows a status badge:

The status card on the same page also surfaces:

• Data exported up to — timestamp of the last successfully exported window (or Never (pending)).
• Next export scheduled — when the next run will happen.
• Export mode — Full history, From setup date, or From custom date (plus the start date where applicable).
• A Last export failed alert with the error message and time when in the Error state.

If a worker crashes mid-export, a 2-hour safety-valve TTL ensures the badge reverts from Running to its underlying state (typically Queued) so the next scheduled run can proceed. Reload the page to see the latest status.

Langfuse retries failed exports on the next run. Repeated failures notify project admins by email and the configured Slack or webhook channel. Configure it under Project Settings → Notifications.

Re-exporting data and configuration changes

Editing an integration — credentials, bucket, prefix, frequency, file type, export source, field groups, or compression — applies to future exports only. It does not re-export data that was already exported (or skipped) under the previous configuration; the export continues from where it left off.

There are two ways to re-export historic data:

1. Change the Export Mode (Full history / From setup date / From custom date). Changing the mode resets the sync position so the new mode's start-date logic takes effect — for example, switching to Full history re-scans from the earliest data. Editing other fields does not reset this.
2. Reset the integration. The Reset button removes the integration; you then reconfigure it from scratch and it starts fresh.

Run Now triggers an immediate export of data since the last sync — it does not re-export history.

Empty files in your bucket

Empty files are expected and normal — they are not an error or a sign of data loss. A given time window may contain data for some tables but not others (for example, observations but no scores in that window). When a table has no data for a window, the exporter may still write a file for it, and that file will be empty.

What an empty file looks like depends on the configured file format:

Build downstream pipelines to tolerate empty files:

• Treat an empty file as "no data in this window for this table," not as a failure, and don't alert on its presence.
• Don't assume a file is always present for every window and table. List the objects in each directory and ingest what's there rather than relying on a fixed file-per-window pattern.
• Point pipelines at the directory (for example observations_v2/ or scores/) rather than parsing filenames. The directory prefixes are stable, but the exact filename format within them is not a stable contract.

Alternatives

You can also export data via:

• UI - Manual batch-exports from the Langfuse UI
• SDKs/API - Programmatic access using Langfuse SDKs or API

---

---