Service Connections

Service connections are the billing unit for server-side SDKs.

What a service connection is

A service connection is one instance of one server-side SDK connected to one LaunchDarkly environment for a period of time measured in minutes. LaunchDarkly treats roughly 43,800 connected minutes, or one full month of continuous connection, as a single service connection. Instances that connect for less than a full month count as a fraction of a connection.

Because billing follows connection time, your usage grows with how many server-side SDK instances connect and how long each stays connected. A single long-lived process that shares one client uses connection time efficiently. Many short-lived or duplicated clients multiply it.

Diagnosing unexpected usage

When service connections grow faster than expected, use both in-platform reporting and a review of where and how you initialize the SDK.

Use in-platform reporting

Open Organization settings and select Plan usage, then open the Service connections tab. Use the reporting to narrow down the source:

• Review the cumulative service connections your account has used over the billing period.
• Review the Peak concurrent connections chart to see the highest number of concurrent server-side connections observed in a single day.
• Filter by project, environment, SDK name, or SDK app ID to isolate which application drives growth.

The SDK app ID reflects the application metadata you configure, so setting accurate id and version information on every server-side application makes this attribution reliable.

To learn more, read the account usage metrics documentation and the service connections documentation.

Initialize the SDK once as a singleton

What to look for: Code paths that create a new server-side client per request, per class, or per module instead of reusing a shared instance.

What good looks like: Each process exposes exactly one client, created early in the application lifecycle and reused everywhere through a shared module or dependency injection container.

Why it matters: Each client instance opens its own connection and accrues its own connection time. Reusing one client per process keeps connection time proportional to your real footprint.

To learn more, read the preflight checklist item SDK is initialized once as a singleton early in the application’s lifecycle.

Watch for forked processes

What to look for: Application servers that fork worker processes to handle requests, common in Ruby and Python, where each worker initializes its own SDK client.

What good looks like: You initialize the SDK deliberately in each forked worker and account for the resulting connections, or you route evaluations through a shared connection where your framework supports it.

Why it matters: Each forked worker maintains its own connection while it lives. A server with many workers multiplies service connections even though it runs one application.

Watch for short-lived and serverless processes

What to look for: Short-lived processes, cron jobs, or serverless functions that initialize a fresh client on each invocation.

What good looks like: Long-running processes reuse a singleton client, and serverless functions initialize the client outside the handler so the platform can reuse it across invocations.

Why it matters: Frequent short connections still accrue connection time. Initializing outside the handler and reusing warm instances reduces both connection churn and initialization latency.

To learn more, read the preflight checklist items Initialize the SDK outside of the handler and Leverage LD Relay to reduce initialization latency.

Centralize where you initialize the SDK

What to look for: Initialization scattered across the codebase, so you cannot easily answer how many clients a deployment creates.

What good looks like: Initialization lives in one well-known place per process, and you can state how many connections each deployment opens.

Why it matters: Connection count is the input to your bill. Knowing exactly where you call init lets you predict service connections and spot unintended clients before they grow your usage.