Data Export usage best practices

This topic explains how LaunchDarkly counts Data Export usage, which settings affect export volume, and how to keep your usage within your plan’s entitlement.

Your LaunchDarkly plan includes a monthly entitlement for Data Export events. A small number of settings affect export volume, and a short periodic audit keeps usage predictable.

How LaunchDarkly counts usage

LaunchDarkly counts Data Export usage differently for streaming and warehouse destinations:

• Streaming destinations, such as Amazon Kinesis, Google Pub/Sub, Azure Event Hubs, mParticle, and Twilio Segment: Every event delivered to every destination counts toward your usage. Two destinations receiving the same environment’s events double your metered usage.
• Warehouse destinations, such as BigQuery, ClickHouse, Databricks, Redshift, Amazon S3, and Snowflake: Usage is measured in rows transferred. An evaluation with a multi-context becomes one row per context kind. For example, an evaluation with user, organization, and device context kinds produces three rows.

LaunchDarkly meters usage per account, per calendar month, summed across all of your projects, environments, and destinations.

Export does not stop when you pass your entitlement. Overage is billed according to your contract terms, so managing volume is your responsibility.

Settings that affect export volume

These settings and behaviors affect export volume, in approximate order of impact:

• Detailed flag events: When you check a flag’s Send detailed events to data export destinations checkbox, every flag evaluation exports a full feature event. If you leave it unchecked, LaunchDarkly does not export evaluation events for the flag unless the flag is in an experiment. On a high-traffic flag, this can be the difference between zero and billions of exported events.
• The environment-level default: The environment setting to send detailed events by default opts every future flag in that environment into per-evaluation export. If you leave it on in a busy environment, volume compounds with every flag you create.
• Experiments and metrics: A flag connected to a metric or running an experiment always sends detailed events. The checkbox is checked automatically and you cannot uncheck it. Attaching an experiment to a high-traffic flag converts summary-only traffic into per-evaluation events.
• Number of destinations: Every enabled destination receives, and meters, a full copy of the environment’s events.
• Context events: index and identify events fire per context, so high unique-context counts add steady baseline volume. Multi-contexts also multiply warehouse rows.
• Custom events: Every track call exports a custom event. Observability SDKs also generate custom events automatically for initialization, errors, and web vitals.
• Debug events: Watching a flag with full fidelity details from the Live events page exports per-evaluation debug events until the debugging session expires.

Manage your export volume

The practices in this section explain how to reduce your event volume, starting with the most impactful.

Audit your detailed events settings

Unintentionally enabled detailed events are the most common cause of high usage. We recommend auditing these settings quarterly:

• Review each environment’s Send detailed events to data export destinations default. Uncheck it unless you deliberately want it, especially in development, staging, and test environments, which rarely need per-evaluation export.
• Review each flag’s Send detailed events to data export destinations setting. Uncheck it for any flag whose per-evaluation data you don’t actively analyze. Unchecking only stops per-evaluation export. Evaluation counts and variation breakdowns remain visible inside LaunchDarkly.

The environment-level checkbox only sets the default for new flags. Turning it off does not change flags that already inherited it, so you must audit flag-level settings as well. The audit script below finds both.

To learn how to change these settings, read Data Export.

Send detailed events only where you use them

For each flag, ask whether a downstream system actually reads that flag’s individual evaluation events. If you only look at aggregates, turn detailed events off. Kill switches, operational toggles, and long-lived permanent flags almost never need per-evaluation export.

Keep experiment volume deliberate

Flags in experiments export detailed events even when the checkbox is unchecked. Time-box experiments on high-traffic flags, and detach metrics when an experiment concludes. A forgotten metric connection keeps full-fidelity export running indefinitely.

Prune destinations and exported environments

Delete destinations that nothing consumes. Each additional destination multiplies your metered usage for that environment.

Streaming destinations allow duplicates in the same environment, so check that you haven’t accidentally created two destinations pointed at the same place.

A destination is scoped to one environment. Export only the environments you analyze, which is usually production. Non-production environments with detailed events enabled are a common silent multiplier.

Check your event kind mix

The Streaming Data Export tab on the Plan usage page breaks down your usage by event kind. To view it, click the gear icon in the left sidebar to view Organization settings, then choose Plan usage. Check which event kind dominates:

• If feature events dominate, audit your detailed events settings.
• If custom events dominate, review your track call sites and observability SDK settings.
• If index or identify events dominate, review your context volume. Whether these event kinds are exported is configurable for your account, so contact Support if you want to change it.

To learn more, read Account usage metrics.

Monitor your usage monthly

Review your usage at least monthly:

• For streaming destinations, the Plan usage page shows your remaining monthly entitlement, and the Streaming Data Export tab shows trends.
• For warehouse destinations, the Warehouse Data Export chart on the Diagnostic usage page displays the number of rows exported.

LaunchDarkly does not send an alert when you approach your Data Export entitlement. To monitor usage automatically, poll the account usage API from your own monitoring and alert at 80% of your entitlement. Use GET /api/v2/usage/data-export-events for streaming events and GET /api/v2/usage/warehouse-export for warehouse rows. To learn more, read Account usage.

Investigate usage spikes at the source

Export volume mirrors your SDK evaluation traffic. A sudden three- to four-times jump in export volume usually means a deploy that evaluates flags in a hot loop, a traffic surge, or a new SDK integration, rather than an export misconfiguration. Confirm whether the underlying evaluation growth is intentional before you adjust export settings.

Coordinate large warehouse operations with LaunchDarkly

Re-syncs and backfills count toward the number of transferred rows. For very large backfills of 10 billion rows or more, work with your account team to create a plan to backfill in smaller chunks.

If your analytics tolerate a few hours of latency, ask your account team about reducing your warehouse sync frequency. Moving from hourly syncs to syncs every four to six hours can cut transferred rows by 75% to 83%.

Audit your configuration with the REST API

This script finds every environment that defaults new flags to detailed events, and every flag currently sending them. Run it once per project:

<CodeBlocks>

$
PROJ="my-project"; API="https://app.launchdarkly.com/api/v2"; AUTH="Authorization: $LD_API_KEY"
$
$
# Environments that default new flags to detailed events
$
curl -s -H "$AUTH" "$API/projects/$PROJ/environments?limit=50" \
>
  | jq -r '.items[] | select(.defaultTrackEvents == true) | .key'
$
$
# Flags sending detailed events in a given environment
$
ENV="production"
$
curl -s -H "$AUTH" "$API/flags/$PROJ?env=$ENV&summary=false&limit=100" \
>
  | jq -r --arg env "$ENV" '.items[]
>
      | select(.environments[$env].trackEvents == true
>
            or .environments[$env].trackEventsFallthrough == true
>
            or (.environments[$env].rules // [] | any(.trackEvents == true)))
>
      | .key'

<CodeBlocks>

Review the resulting list of flags and turn off detailed events for any flag whose per-evaluation data you don’t use. If you have more than 100 flags, page through the results with the offset parameter.

Find your highest-volume sources with SQL

If you export to a warehouse, a few queries over the exported tables show where your volume comes from. Each warehouse destination contains a single environment’s data, so run these queries once per destination schema.

Here is how to find your volume trend, top flags, and biggest multipliers:

<CodeBlocks>

1
-- 1. Daily volume trend: spot surges and when they started
2
SELECT DATE_TRUNC('day', received_time) AS day, COUNT(*) AS exported_rows
3
FROM evaluation_events
4
WHERE received_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
5
GROUP BY 1 ORDER BY 1;
6
7
-- 2. Top flags by exported rows: your detailed events audit shortlist
8
SELECT flag_key, COUNT(*) AS exported_rows,
9
       ROUND(100 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct_of_total
10
FROM evaluation_events
11
WHERE received_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
12
GROUP BY 1 ORDER BY 2 DESC LIMIT 20;
13
14
-- 3. Volume you can switch off (detailed events setting) compared to
15
--    experiment-driven volume (exports regardless of the setting)
16
SELECT IFF(experiment_iteration_id IS NOT NULL,
17
           'experiment exposure (exports regardless of setting)',
18
           'detailed events setting') AS export_cause,
19
       COUNT(*) AS exported_rows
20
FROM evaluation_events
21
WHERE received_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
22
GROUP BY 1;
23
24
-- 4. Multi-context fan-out: average exported rows per evaluation,
25
--    and the context kind mix
26
SELECT ROUND(COUNT(*) / COUNT(DISTINCT event_id), 2) AS avg_rows_per_evaluation
27
FROM evaluation_events
28
WHERE received_time >= DATEADD('day', -30, CURRENT_TIMESTAMP());
29
30
SELECT context_kind, COUNT(*) AS exported_rows
31
FROM evaluation_events
32
WHERE received_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
33
GROUP BY 1 ORDER BY 2 DESC;
34
35
-- 5. Top metric keys driving metric_events
36
SELECT event_key, COUNT(*) AS exported_rows
37
FROM metric_events
38
WHERE received_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
39
GROUP BY 1 ORDER BY 2 DESC LIMIT 20;
40
41
-- 6. Compare environments: replace the schema names with your destination schemas
42
SELECT 'production' AS env, COUNT(*) AS exported_rows FROM LD_PROD.evaluation_events
43
UNION ALL
44
SELECT 'staging', COUNT(*) FROM LD_STAGING.evaluation_events;

<CodeBlocks>

If one flag dominates query 2, check its detailed events setting. If query 3 shows mostly experiment-driven rows, review your experiments, because unchecking the flag setting will not reduce those rows. If query 4’s multiplier is well above one, multi-contexts are inflating your row counts.

These examples use the Snowflake syntax. Use the dialect that corresponds to your warehouse. Functions like DATEADD, DATE_TRUNC, and IFF vary by engine, but the structure of each query does not.

To learn more about the exported tables, read Warehouse Data Export schema reference.

Conclusion

In this guide, you learned how LaunchDarkly counts Data Export usage, which settings affect export volume, and how to audit and reduce your usage with the LaunchDarkly UI, the REST API, and warehouse SQL.