Service connections and client-side monthly active users (MAU) are the two metrics that most LaunchDarkly customers are billed on. LaunchDarkly splits its SDKs into server-side SDKs, which hold a persistent streaming connection to LaunchDarkly, and client-side and edge SDKs, which run in browsers, devices or at the edge. The first group is measured in service connections and the second in MAU.[1] The documentation notes that for most customers MAU is used to calculate billing, while server-side SDKs use service connections as the billing metric.[2]
Editions
Both metrics appear on every plan. The free Developer plan includes 5 service connections and 1K client-side MAU per month.[5] The Foundation plan includes the first 5 service connections each month, bills additional connections at $10 each per month, and shows $8.33 per 1k client-side MAU per month on yearly billing.[5] Enterprise entitlements are custom.[5] Some customers are billed by service connections and others only by MAU, and the customer is told to contact its LaunchDarkly representative to learn more about its client-side usage billing model.[2]
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.[1] See Service connection. The unit is defined by the connection, not by the host: an SDK can initialize in a server, virtual machine, pod, container, ephemeral process or serverless function, and each unique connection between an SDK and an environment counts individually.[1]
How connections are calculated
LaunchDarkly accrues one service connection when one server-side SDK stays connected to one environment for a full month. It calculates connections from the number of minutes per month connected and assumes 43,800 minutes per month.[1] Key points:
- Connections can scale up and down. They are not rounded up or down, but may be combined: two connections that each stay connected for half a month are calculated as one service connection.[1]
- Connections to pre-production environments are included for billing purposes.[1]
- Multiple SDKs or SDK instances in one application each count for every unique connection to an environment. The documentation’s examples show two servers with three applications each as six service connections, and one server with ten applications as ten.[1]
- Client-side SDKs are not counted as service connections.[1]
For estimation, LaunchDarkly suggests counting the back-end services running a server-side SDK, such as pods, containers, virtual machines and replicas.[1]
Serverless, Ruby, Python, PHP and polling
In a serverless architecture the SDK is initialized at function initialization time. If the average invocation lasts one minute, each invocation counts as 1/43,800 of a service connection, and at one second as 1/2,628,000. LaunchDarkly measures at one-minute granularity and records a representative sample for shorter invocations.[1]
Ruby and Python applications fork processes to handle requests, so an SDK instance must be initialized for each process, and the connection lasts only as long as the process exists.[1] PHP’s architecture prevents the streaming connection from being used across requests, so PHP SDKs poll for flag values, and Apex SDKs work similarly.[1]
Polling mode is billed in poll requests: LaunchDarkly treats 732 monthly poll requests from an SDK as one service connection, assuming 30.5 days of 24 hours, so one request per hour costs the same as a persistent streaming connection. Polling more often raises cost and polling less often lowers it.[1] LaunchDarkly does not recommend polling mode except where streaming does not fit the use case.[1] Because Ruby, Python, serverless and Kubernetes architectures generate many connections, the pricing page offers special tailored rates for them.[5]
Relay Proxy
If the customer uses the Relay Proxy, LaunchDarkly calculates the bill from the number of server-side SDKs connected to the Relay Proxy. For highly secure infrastructure where the Relay Proxy runs in offline mode, customers are told to contact Sales to determine the best solution.[1] The count is therefore by connected server-side SDKs, as with a direct connection.
Tracking and controlling
The Service connections tab shows cumulative or incremental usage by dimension, including project, environment, connection type, relay version, SDK name, SDK type, SDK version or SDK App ID.[3] Connections from SDKs without an application ID configured appear as “Unknown”.[1] Application metadata therefore lets a licence manager attribute connections to applications.
Incorrectly implemented SDKs are called out as a common cause of unexpected high bills. Symptoms include a large number of service connections, and the recommended fix is to implement SDKs as a singleton and reuse the client throughout the application.[2] Two patterns inflate counts: over-instantiation, which creates multiple instances, and runaway instantiation, which creates new instances throughout the application’s life, for example in a loop or a request handler.[2]
Client-side 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.[2] See Client-side MAU. A context represents an entity evaluated for flags, such as a user or device, and has a context kind and a unique key.[2]
Counting rules
- Usage is the total number of unique context keys evaluated in a month.[2]
- Changing an existing context key makes the new key unique and counts as an additional MAU. Custom attributes do not affect uniqueness.[2]
- If the same context appears in multiple environments or projects, it counts only once toward MAU.[3]
- LaunchDarkly uses the single context kind with the highest number of unique contexts in a month. With 2,000,000 users and 500,000 devices, MAU is 2,000,000 on the user kind; with 2,000,000 users and 4,000,000 devices, MAU is 4,000,000 on the device kind.[2] Client-side billing is described as being only for the context kind used most.[1]
- The Client-side MAU tab can be viewed by project, environment, SDK name, SDK app ID or anonymous contexts, and as cumulative, incremental or rolling 30-day counts.[3]
Limits and stored contexts
When a customer subscribes to a plan it commits to a certain number of MAU each month. LaunchDarkly says it never stops or throttles service when the MAU limit is exceeded, and all contexts keep receiving flags correctly.[2] Overage is billed in arrears. For a Foundation plan the customer can update its monthly entitlements at any time on the Billing page.[6]
There is no limit on the number of contexts a customer can evaluate or target, but LaunchDarkly stores only a limited number of unique context keys per environment and per 30-day period, and stored contexts are what count toward billing metrics such as MAU.[4] The documentation warns that creating contexts with request IDs, server-to-server contexts with no human operators, or timestamp identifiers generates unexpectedly high usage, because each unique key is stored.[4] Context instances remain on the Contexts list for 30 days from last evaluation or until an environment reaches 3,000,000 context instances.[2] See Stored context (context key).
Anonymous contexts
Anonymous contexts do not appear on the Contexts list, but they are still identified by unique keys and can raise MAU.[4] One person who is first anonymous and later logs in can be represented by two unique keys, and if keys are managed manually they can conflict with the SDK’s internal key management and inflate MAU.[4]
Practical points for asset managers
- Build an inventory of server-side applications by environment, including staging and test, because pre-production connections are billed.[1]
- Configure application IDs so connections are attributable by application on the usage page.[1]
- Check for per-request or per-timestamp context keys, which inflate stored contexts and MAU.[4]
- Review polling and serverless usage, since both change the cost per SDK instance compared with a long-running streaming connection.[1]
- The Terms of Service prohibit permitting access or use that circumvents or attempts to circumvent a contractual usage limit.[7] Entitlement sizing should therefore follow the documented counting rules.
Out of scope
Experimentation keys, AI runs and observability categories are covered in LaunchDarkly Experimentation, AI runs and observability usage. Plan prices and billing cycles are in LaunchDarkly plans, pricing and billing.