Calculating billing

Overview

This topic explains how LaunchDarkly calculates billing for your account.

LaunchDarkly calculates your billing based on different aspects of your system usage. Depending on your billing model, you may be billed for more than one of the account usage metrics displayed on the Usage page.

Foundation, Enterprise, and Guardian plans

Different features are included in different plan tiers. Foundation, Enterprise, and Guardian plans can include monthly entitlements for monthly active users (MAU), service connections, AI runs, observability, and Experimentation.

For self-serve plans, LaunchDarkly bills you at the beginning of each month for any usage exceeding your entitlements from the prior month. Throughout the month, LaunchDarkly sends an email notification to your account owner and billing contact when your overage balance exceeds various dollar amounts.

Developer plans

Developer plans are free to use, and include limited monthly entitlements for MAU, service connections, AgentControl config evaluation runs, observability, and Experimentation. For this plan, LaunchDarkly warns you when you are approaching the limit of these entitlements, and sends additional notifications when your usage has exceeded them. If your usage continues to exceed these entitlements, your plan will convert to read-only mode.

Monthly active users (MAU)

MAU is the number of unique monthly active contexts, typically user contexts, evaluated by LaunchDarkly client-side, AI, and edge SDKs. (Server-side SDKs use service connections as the billing metric.)

For most customers, MAU is used to calculate billing.

MAU is calculated based on contexts. A context represents an entity evaluated for flags, such as a user or device. Each context has a context kind, for example user or device, and a unique key that identifies that context.

Each context key is used to calculate MAU. Usage is based on the total number of unique context keys evaluated in a month. If you change an existing context key, LaunchDarkly considers the new key unique and counts it as an additional MAU. Custom attributes do not affect uniqueness.

When you subscribe to a LaunchDarkly plan, you commit to a certain number of MAU each month.

MAU for context kinds other than user

For most LaunchDarkly customers, MAU is the number of monthly active users. However, if your greatest-used context kind by volume is something other than user, LaunchDarkly calculates MAU using that context kind.

LaunchDarkly uses the single context kind with the highest number of unique contexts in a month to calculate MAU. For example:

• If you use 2,000,000 users and 500,000 devices, your MAU will be 2,000,000, based on user.
• If you use 2,000,000 users and 4,000,000 devices, your MAU will be 4,000,000, based on device.

MAU limits

The LaunchDarkly plan you subscribe to may include a MAU limit. We understand that a company’s customer base can grow unexpectedly over time. We never stop or throttle service if you exceed your MAU limit. All contexts will continue to receive feature flags correctly, regardless of the amount of your MAU.

Context instances appear on the Contexts list for 30 days from their last evaluation, or until the environment reaches 3,000,000 context instances. To learn more, read Manage stored contexts.

If you have configured LaunchDarkly to use anonymous contexts, that can impact your MAU as well. To learn more, read Manage anonymous contexts.

To learn more about your client-side usage billing model, contact your LaunchDarkly representative.

Service connections

Some customers are billed by service connections. A service connection is one instance of one server-side SDK connected to one LaunchDarkly environment for a time period measured in minutes. To learn more, read Service connections.

If you subscribe to a LaunchDarkly plan, you commit to a certain number of service connections each month. LaunchDarkly will also bill you at the beginning of each month for any usage in excess of these prepaid entitlements from the prior month. You can change your monthly entitlements from the Billing page. To learn more, read The Billing page.

AgentControl

AgentControl is billed based on AI runs. An AI run is counted each time a model is called or a judge runs, whether standalone or attached to an AgentControl config. In practice, this covers three scenarios: a model call in a production workflow, an online eval, or a direct judge call. Observability traces are optional and do not affect your run count. AI runs are tracked automatically from events emitted by the AI SDK and recorded in the event recorder. No additional instrumentation is required.

Decreasing your AI run costs

To reduce costs, lower the sampling percentage on your AgentControl config. This controls how often the judge runs on live traffic. A lower percentage means fewer judge calls and lower online eval costs.

Experimentation

Depending on your billing model, if you use Experimentation, you may be billed by Experimentation keys or Experimentation MAU. If you are unsure how you are being billed for Experimentation, contact your LaunchDarkly representative.

Experimentation keys

Some customers are billed by Experimentation keys.

Experimentation keys include the total number of unique context keys, from server-side, client-side, AI, and edge SDKs, included in each experiment:

• if the same context key is in one experiment multiple times, LaunchDarkly counts it as one Experimentation key
• if the same context key is in two different experiments, LaunchDarkly counts it as two Experimentation keys

Your total usage of Experimentation keys measures how many contexts you are targeting in your experiments.

If you subscribe to a LaunchDarkly plan, you commit to a certain number of Experimentation keys each month. LaunchDarkly will also bill you at the beginning of each month for any usage in excess of these prepaid entitlements from the prior month. You can change your monthly entitlements from the Billing page. To learn more, read The Billing page.

For some annual billing plans, you commit to a certain number of Experimentation keys each month. If you consistently go over your plan limits, averaged over a quarter, we will “true forward” your contract based on your actual average use. To learn more about your Experimentation billing plan, contact your LaunchDarkly representative.

Experimentation MAU

Some customers are billed by Experimentation MAU.

Experimentation MAU is the number of unique monthly active contexts, typically user contexts, evaluated by LaunchDarkly server-side, client-side, AI, and edge SDKs and eligible to be included in an experiment.

Experimentation MAU is based on the total number of unique contexts across your account for the month, whether or not those contexts are actually included in an experiment. Uniqueness is defined by unique context keys. If you change a context’s key, LaunchDarkly counts it as a new MAU. Custom attributes do not affect uniqueness.

If a context is included in more than one experiment within a month, it still counts as one MAU.

Observability

If you subscribe to a LaunchDarkly plan, you are entitled to a certain number of observability products each month. LaunchDarkly will bill you at the beginning of each month for any usage in excess of these prepaid entitlements from the prior month.

The LaunchDarkly observability feature is billed by the following products:

• Monthly ingested sessions
• Monthly ingested errors
• Monthly ingested traces
• Monthly ingested logs

To estimate your monthly costs for observability, use our observability usage calculator.

Identifying causes of unexpected high bills

Billing issues can be complex and unique to your account. As a best practice, we recommend taking questions about your LaunchDarkly bill to your LaunchDarkly representative.

However, customers on Foundation plans or who otherwise do not have access to a LaunchDarkly representative may find it helpful to understand how to investigate unexpected high bills. A common cause of unexpected high bills is incorrectly implemented SDKs. In almost all cases, we recommend that you implement SDKs in a singleton pattern.

Symptoms of not following the singleton pattern

An incorrectly implemented SDK can result in a number of different symptoms. Common symptoms include:

• Large number of service connections
• Increased CPU or memory usage
• Frequent connectivity errors, such as connection timeouts or dropped connections
• Experiments missing events
• Flags reflecting default or stale values because they are unable to connect to LaunchDarkly

Correctly implementing the singleton pattern

Here are some best practices for correctly implementing the singleton pattern:

• Create a singleton for the SDK and make sure it’s reused throughout your application.
• Inject the singleton into dependent classes, or pass it explicitly, rather than instantiating it directly.
• Centralize SDK initialization so you initialize one time, during application setup, and reuse the SDK client through the lifecycle.
• Lazy load safely. In some SDKs, the initialization method returns a promise. Make sure to either set your client variable to the actual initialized SDK client, or wait for the promise to resolve.

Identifying incorrect SDK implementations

There are two common coding patterns that result in the unintentional creation of multiple SDK instances. These patterns are:

• Over-instantiation: In this situation, you unintentionally create multiple instances. This can lead to inflated service connection costs and may contribute to performance issues as you scale.
• Runaway instantiation: In this situation, you unintentionally create new instances throughout the lifespan of your application. This can lead to explosive service connection costs and nearly always cause performance issues, regardless of scale.

Examples of over-instantiation include:

• Instantiating in multiple classes. In this case, each service creates its own SDK instance, which results in multiple unnecessary connections.
• Improperly implemented lazy loading. In some SDKs, the initLDClient function returns a promise. If you use a helper method to set ldClient to that promise rather than to the actual initialized SDK client, then you can end up with multiple SDK instances by making multiple calls to your helper method before the first initLDClient call resolves. This can lead to unexpected behavior or resource overuse. This asynchronous gap can also cause problems in applications where proper initialization and single-instance management of the SDK are critical. The SDK is designed to be initialized once per application instance, so it is important to ensure proper lazy loading without redundant initializations.

Examples of runaway instantiation include:

• Instantiating inside a loop or recurring function. In this case, each iteration of the loop or function creates a new SDK instance, which results in a large number of unnecessary connections.
• Instantiating in a request handler or other short-lived context. In this case, a new SDK instance is created for each request, which results in a large number of unnecessary connections.