Product Features

  • Does LaunchDarkly support SSO?

    LaunchDarkly supports single-sign on with SAML 2.0. All identity providers that support SAML 2.0 should work with our platform. We've tested support for the following SAML 2.0 identity providers:

    • Okta
    • OneLogin
    • Azure Active Directory
    • Google Apps
    • Active Directory Federation Services (ADFS)
    • PingIdentity
    • Centrify
    • Duo
    • SecureAuth

    We have official apps already built for Okta, OneLogin, and Azure. See our documentation for complete setup instructions as well as configuration tips for some specific providers.

  • User Targeting

    LaunchDarkly targeting lets you turn features on or off for individual users or groups of users. You can use the Targeting tab to roll features out for internal testing, private betas, or usability tests before performing a broader rollout. You can create your own rules to target who you want, when you want.

    Learn more about targeting users in our documentation here.

  • Targeting by attribute

    In addition to targeting individual users, LaunchDarkly allows you to set up targeting rules that target users by attribute. 

    Each rule has three parts: an attribute, an operator, and a user value.   You can create as many custom targeting rules as you want for each feature flag and even perform percentage rollouts for each rule.

    All users that have not been individually targeted or who are not targeted by a custom rule will be evaluated by the default rule.

    Learn more

  • Flag management dashboard

    LaunchDarkly provides you with a centralized dashboard to manage the lifecycle of your features from local development, to QA, to production. Manage multiple different software projects with their own development environments.

  • Projects and environments to manage your development process

    Projects allow you to manage multiple different software projects under one LaunchDarkly account. For example, you can create one project called Mobile App and another project called Web App. Each project will have its own unique set of environments and feature flags. By default, all team members in your LaunchDarkly account will have access to every project within that account.

    Environments allow you to manage your feature flags throughout your entire development lifecycle — from local development to QA, staging, and production.

    When you first sign up, you're provided with two environments within a project. By default, they're named Test and Production. Each environment has its own private SDK key, which is used to connect a LaunchDarkly SDK to a specific environment.

    Each feature flag that you create has its own unique set of targeting rules for each environment. This means that you can change your flag rollout rules in a development or staging environment for QA testing before rolling out to production.

  • The Debugger: Real-time feature flag events

    The debugger helps you test whether you've set up LaunchDarkly correctly. From the debugger, you can see your users' feature flag requests and events in real-time.

    You can access the debugger from the sidebar. The debugger must be the active tab in its browser window in order for events to appear. You can have a second window open with your application, if you need to click around in your app in order to generate events.

    Please note that in high-volume environments, the events sent to the debugger may be sampled. When this happens, you will see a subset of events on the debugger, instead of every event.

    The debugger is helpful for troubleshooting that you're successfully sending events to LaunchDarkly and is not intended as a source of truth for the variations your users are receiving. The debugger displays real-time events only and does not keep a historical record of this data. 

    Read more about the debugger in our documentation.

See all 11 articles

Use Cases

  • Can you schedule a flag?

    LaunchDarkly does not have a built in way to schedule a flag for a particular date, however this can be achieved with targeting rules. For example, you may want to serve true to show your feature, but only after November 19th, 2018.

    You can use the before/after operator to compare dates in your targeting rules. You'll simply need to include the current date as a custom attribute in your user object and then set up a targeting rule that evaluates to true if the date value in your user object is after the date specified in your targeting rule. Note that dates must be formatted in unix milliseconds for date comparisons. You can reference this in our documentation here

    Here's an example in JavaScript showing how to include the current date in unix milliseconds in your user object:

    var user = {
    "key": "67yx27g7fxl004483",
    "custom": {
    "current_date": new Date().getTime()

    And here's a screenshot showing how the targeting rule would look in the UI:

    This example user will evaluate to `true` because their current date attribute is after the date specified in the flag's targeting rules.

  • Is it required to use a unique key for anonymous users?

    Anonymous users work just like regular users, except these users are not stored in your dashboard. One of the primary reasons that users are sent anonymously is to avoid having a lot of unauthenticated users polluting the user dashboard. Another reason is to avoid sending PII, but we recommend the use of private user attributes if that is the case. 

    There are some cases where you do need to generate a unique key for anonymous users. If you are targeting users individually by key, using LaunchDarkly's A/B testing feature, or the Analytics Data Stream you would want unique keys. You also want unique keys when conducting percentage rollouts. For that reason, the general documented advice is to treat the anonymous users like regular users and assign unique IDs. 

    If you do not have a need to uniquely identify your anonymous users, you could use a shared key for these users.

  • How are A/B Test Results Calculated?

    When a conversion event comes in, we try to find the 'closest' feature event. To do this, we look for the latest feature event for this user in the 24 hours preceding the conversion event. (Failing that, we will look for the earliest feature event for that user in the 5 minutes following the conversion event, to allow for clock skew). Once we find a feature event, we look at which variation that user saw, and we add the user to the set of users who saw that variation and converted.

    So, suppose the following timeline:

    t0: user X sees variation A
    t1: user X sees variation B
    t2: user X triggers a conversion event

    As long as there is less than 24 hours between t2 and t1, user X will be added to the variation B conversion set (and *not* the variation A conversion set).

    In this same timeline, but when there is more than 24 hours between t2 and t1, we will not find a feature event, so the conversion will not count at all.

    Suppose an alternate timeline:

    t0: user Y sees variation A
    t1: user Y triggers a conversion event
    t2: user Y sees variation B
    t3: user Y triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Y will be counted in both the variation A conversion set *and* the variation B conversion set. 

    Now, suppose a third timeline:

    t0: user Z sees variation A
    t1: user Z triggers a conversion event
    t2: user Z sees variation A
    t3: user Z triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Z will be counted *once* in the variation A conversion set.

    Keep in mind that the important time limit here is 24 hours. If someone converts 5 days (or 2 days) after (or 2 days) getting a variation, they will not be counted.

    Contact us at if you have any additional questions.

  • Feature Flag Driven Development

    Feature flags/toggles/controls harness the power of test-driven development (TDD).   This is the process of releasing and iterating features quickly, testing those features, and making improvements.  Think of it as Lean UX methodology.  You release light features to receive market feedback.  You iterate on that feedback, make improvements, and redeploy.

    Think of feature flag-driven development as a way to receive iterative market feedback on your product, rather than solely depend on isolated customer feedback.  It’s a way to test how your features perform in the real world and not just in an artificial test environment.

    Read the full article

  • Creating a feedback loop with LaunchDarkly
    Customers use LaunchDarkly to deploy a new feature to a small subset of their users. The platforms lets you easily segment users. For example, you can:


    • Rollout to a percentage of total users
    • Create a beta group of hand-picked users
    • Give early access to a single VIP customer
    • Dogfood to internal users only
    • Create an “opt-in” allowing users to self-select to see new features
    Once you’ve rolled out the feature to a group, measure it to see if the feature has impacted behavior as you expected and use that feedback to inform your path. Fix issues and make changes as necessary then continue to rollout incrementally to the entire base.
  • Empowering team collaboration and non-technical users
    LaunchDarkly allows teams to develop software in a way that’s fundamentally healthier, removing friction from the Product and Engineering relationship. The results are a dramatic savings in time and focus as well as faster delivery with greater trust.
    Empowered product development means that both technical and non-technical team members can collaborate on software releases. Because feature rollout will be decoupled from code deployment, team members outside of Engineering would be able to control the visibility of particular features without compromising the app’s integrity. Product and QA teams are empowered to make changes to feature visibility without consuming engineering resources.
    LaunchDarkly offers end to end feature flag management to allow an entire product development organization to control who gets the right feature, when.
    • Facilitate coordination between Engineering and Product, allowing you to break up larger features into smaller deployments and release features faster to select customers
    • Give control to the Product team, taking the burden of re-deploying off of engineering
    • Reduce friction between teams, cultivating a healthier and more productive relationship
See all 7 articles