Service connections

This topic explains what service connections are and how LaunchDarkly uses them to calculate your bill.

Overview

This topic explains what service connections are and how LaunchDarkly uses them to calculate your bill.

About service connections

When a LaunchDarkly server-side SDK initializes, it creates a persistent streaming connection that allows you to update flag values in near real-time. LaunchDarkly SDKs can initialize in a virtual or physical operating system (OS) instance, such as a server, virtual machine (VM), pod, or container. They can also initialize in ephemeral processes and serverless architecture.

A service connection is one instance of one server-side SDK connected to one LaunchDarkly environment for a time period measured in minutes.

Only server-side SDKs count toward measuring service connections. Unlike server-side SDKs, client-side SDKs are measured by the number of contexts they encounter, not by the relationship between the SDK and an environment. To learn more, read How client-side and edge SDKs affect billing.

Each application instance you are running across your production and pre-production environments counts toward your service connections. If you have multiple SDKs or SDK instances in the same application, each unique connection between an SDK and an environment counts as an individual connection.

You can use application metadata from your SDKs to see which applications are using each Service Connection. When configured, this metadata appears as the SDK App ID dimension on the Service connections usage page. Connections from server-side SDKs that do not have applicationId configured appear as “Unknown.” To learn how to send application metadata, read Application metadata configuration.

How service connections affect your bill

LaunchDarkly offers monthly and annual billing options. We can also customize billing plans to more precisely meet your needs.

If you subscribe to a monthly or pay-as-you-go plan, you commit to a certain amount of service connections each month. You can change your monthly entitlements from the Billing page. To learn more, read The Billing page.

If you use the monthly billing option, LaunchDarkly will bill you at the beginning of each month for any usage in excess of these prepaid entitlements from the prior month. Customers on annually invoiced plans are billed annually.

To learn more about how to control billing costs, read Identifying causes of unexpected high bills.

How we calculate service connections

A LaunchDarkly service connection is based on connection time. You accrue one service connection when one server-side SDK stays connected to one LaunchDarkly environment for a full month. This is because much of the value you get from LaunchDarkly is based on the persistent connection that offers you control over your software. We calculate service connections based on the number of minutes per month you are connected to LaunchDarkly. LaunchDarkly assumes 43,800 minutes per month.

This table shows examples of how LaunchDarkly calculates total service connections:

Servers	Applications or services running	Connection time	Total service connections
1 server	1 application	x 1 month	= 1 service connection
2 servers	1 application each	x 1 month	= 2 service connections
1 server	10 applications each	x 1 month	= 10 service connections
2 servers	3 applications each	x 1 month	= 6 service connections
1 server	1 application	x 0.5 months	= 0.5 service connections
2 servers	1 application each	x 0.5 months	= 1 service connection
2 servers	1 application each	x 1 month (server 1) x 0.5 months (server 2)	= 1.5 service connections

You can scale service connections up and down. Our calculation will align with the total amount of time each service connection is connected to LaunchDarkly. We do not round service connections up or down, but we may combine them: if one service connection is connected to LaunchDarkly for half of a month and another service connection is connected for half of a month, we calculate that as one service connection. We also include connections to pre-production environments as service connections for billing purposes. We support your unique architecture by focusing on the time spent connected, and calculating the service connections for you.

A good way to estimate your potential service connections is to count the total number of back-end services that use a LaunchDarkly server-side SDK and are running your application. These services might be pods, containers, virtual machines, replicas, environments, and so on. For example, how many containers are running across your EC2 instances? How many committed pods do you have running in Kubernetes monthly? You can also contact Sales to discuss your potential service connection usage in more detail. If you are an existing customer and have questions on your service connection usage, start a Support ticket.

Here are three examples of Amazon ECS cluster configurations and how many service connections each configuration would result in:

Server-side SDKs and service connection-based billing

Certain SDKs have special considerations regarding streaming connections to LaunchDarkly.

Ruby and Python

Ruby and Python applications operate in web contexts that fork off processes to handle requests. In both languages, you must initialize an instance of the SDK for each process. That connection is only maintained for as long as the process exists.

PHP and Apex

PHP’s shared-nothing architecture prevents LaunchDarkly from using the streaming API connection across requests. Because of this, LaunchDarkly’s streaming API does not connect to PHP SDKs. Instead, the SDK polls for flag values. Apex SDKs operate in a similar way. To learn more, read How an SDK in polling mode affects billing.

The Launch

Darkly Relay Proxy and service connection-based billing

If you use the Relay Proxy, we calculate your bill based on the number of server-side SDKs connected to the Relay Proxy.

Relay Proxy offline mode

In highly secure infrastructure, you can use the Relay Proxy in offline mode. In this circumstance, contact Sales to determine the best solution for your needs.

Serverless architecture and service connection-based billing

In a serverless architecture, you initialize the LaunchDarkly SDK at function initialization time to call for the flag values. Assuming a service connection averages 43,800 minutes if your average invocation duration is one minute, we count each invocation as 1/43,800 of a service connection. If your average duration is one second, we count each invocation as 1/2,628,000 of a service connection.

LaunchDarkly measures service connections with one-minute granularity. If your average duration is less than one minute, we record a representative sample of execution each minute.

In order to estimate your usage for a serverless architecture, we use the average duration of your Lambda and the number of invocations per month.

Here are some representative examples of this calculation:

Average Lambda duration	Example service connection calculation
Many minutes	Each invocation is billed for the time it actually runs, rounded to the nearest minute: 1/43,800 of a service connection each minute.
Between one and two minutes	Imagine a scenario where each invocation lasts 75 seconds. LaunchDarkly will sample each Lambda invocation once, and the invocation will be billed at minimum one minute (1/43,800 of a service connection). One quarter of invocations, on average, will cross the one minute sample boundary twice and be billed for two minutes (2/43,800 service connection). The total service connections billed therefore averages out to 75 seconds per Lambda invocation.
A few seconds	Imagine a scenario where you have a single Lambda function with an average duration of 15 seconds. If this Lambda is invoked four times within a minute, it accumulates a total runtime of 60 seconds. LaunchDarkly samples at the beginning and end of the minute, so the sampling records, on average, only one of the four Lambda invocations. Therefore, we count this as just 60 seconds of connection time or 1/43,800 of a service connection.
Less than a second	LaunchDarkly samples the number of running Lambdas each minute, and bills 1/43,800 of a service connection for each one. If your average Lambda duration is 100ms, LaunchDarkly will record 1/600 of the actual invocations, but bill each one for 60,000ms (the one-minute minimum granularity), which averages out to the same cost.

To determine your Lambda function’s average invocation duration, refer to your AWS console.

How an SDK in polling mode affects billing

We do not recommend using polling mode except in specific situations where streaming mode does not support your use case.

You can configure an SDK to poll LaunchDarkly at certain intervals to download flag values, rather than maintaining a persistent connection. Persistent SDK connections follow our best practices and allow for near-instantaneous streamed flag updates, which are more powerful because they don’t introduce a delay, but in some circumstances polling may be appropriate.

LaunchDarkly calculates 732 monthly poll requests from an SDK as one service connection. This assumes 30.5 days per month, and multiplies that by 24 hours for each day. This calculation means one polling request per hour per service connection costs the same as maintaining one persistent streaming connection per service connection. If you configure an SDK to poll more frequently, your costs will increase. Likewise, if you configure an SDK to poll less frequently, your costs will decrease, but flag updates may occur more slowly than they did before the change. To learn more about configuring your SDK, read Configuration.

How client-side and edge SDKs affect billing

Client-side and edge SDKs are billed by monthly active users (MAU) instead of by service connections. MAU is calculated by the number of contexts encountering your client-side and edge SDKs. A context is defined as any unique entity that encounters a feature flag. You are only billed for the context kind you use the most. We refer to this context kind as the “user” in “monthly active users (MAU).” MAU-based billing occurs every month.