# Catch feature flags that never got switched on in production

> Every weekday we compare your staging and production feature settings and flag only the differences that could be hurting customers.

- Workflow type: agent
- Services: LaunchDarkly, Slack, Linear
- Categories: Engineering, Operations
- Published: 2026-08-31

## What it does

- Checks every feature flag each weekday morning and compares how it is set in staging against how it is set for real customers in production.
- Sorts the harmless differences from the risky ones, so a feature part way through a rollout does not get reported alongside a feature that works in staging but was never switched on for customers.
- Posts one ranked summary to your release channel listing only the mismatches worth acting on, and stays quiet on days when everything lines up.
- Opens a ticket for the highest risk mismatches so each one gets an owner, without raising a second ticket for something already reported in the last two weeks.

## What you'll need

- A LaunchDarkly account with at least two environments, such as staging and production.
- A Slack workspace and the channel your team watches for releases.
- A Linear workspace and the team that should pick up flag cleanup work.
- Read access to LaunchDarkly is enough, since this never changes your flags.

## Prompt

Every weekday at 8am, audit my LaunchDarkly feature flags for configuration drift between environments and tell me which mismatches are actually risky. Compare my staging environment against my production environment. Keep the LaunchDarkly project key, the two environment keys, the Slack release channel, and the Linear team as configuration at the top of the workflow so they are easy to change later.

Start by pulling every flag in the project with its per environment configuration using LaunchDarkly's "List feature flags" operation, following pagination until you have the full set. Then call "List feature flag statuses" once for staging and once for production, so you know which flags are actively being evaluated in each environment and when each one was last requested. For any flag whose targeting looks like it diverges between the two environments, call "Get feature flag" to inspect the per environment configuration closely before you judge it.

For each flag, compare staging against production on three things: the on/off state, the default variation served when the flag is on and when it is off, and the targeting rules, including percentage rollouts and individually targeted contexts.

Then judge each difference instead of reporting all of them. Differences that are usually intentional include a flag mid rollout where production is serving a percentage rollout, an environment only kill switch, and a flag that is brand new and has only been configured in staging so far. Differences that are usually dangerous include a flag that is on and actively evaluated in staging but has never been enabled in production, which normally means a finished feature customers never received, and the two environments serving different variations with no rollout in progress. Treat a flag that is off in staging but on in production as risky too, since it means something is live for customers that nobody is exercising in a test environment. Use the last requested timestamps to tell a genuinely live flag apart from one that no code path touches any more.

Post one ranked digest to my release channel with Slack's "Send a Message" operation, ordered by risk with the most dangerous mismatches first. List only the risky mismatches, and for each one give the flag key, exactly what differs between staging and production, and which environment looks wrong. Write it so an on call engineer who has not opened LaunchDarkly yet can act on it, and quote flag keys directly, since LaunchDarkly addresses flags by human readable project, environment, and flag keys rather than ids. On days when nothing is worth flagging, stay silent and post nothing at all.

For anything ranked high risk, open a Linear issue with the "Create Issue" operation, naming the flag key in the title and describing the drift and which environment looks wrong in the body, so it gets an owner. Before creating one, use "Search Issues" to look for a matching issue for that same flag key created in the last two weeks, and skip it if one already exists so we never file duplicates.

This must stay strictly read only against LaunchDarkly. Report and ticket the drift, and never toggle a flag, edit targeting, or copy flag settings between environments automatically. Do not build any part of this on LaunchDarkly approvals, scheduled changes, flag triggers, or the copy feature flag operation, since those are plan gated and fail on lower plans. Remediation stays manual by design.

## How to customize

- Change the schedule or the time of day, for example a single Monday morning check instead of every weekday.
- Pick which two environments get compared, such as development against staging instead of staging against production.
- Adjust what counts as high risk and therefore earns a ticket, and choose which channel and which Linear team receive the output.

## FAQ

### Will this change any of my feature flags?

No. It only reads your flag settings and reports what it finds. It never switches a flag on or off, edits targeting, or copies settings from one environment to another. Read only access is enough.

### Will it message us every single day?

No. It stays silent on days when nothing risky turns up, so a message in the channel always means there is something worth looking at.

### How does it know a difference is a real problem and not just a rollout in progress?

It looks at whether each feature is actually being used in each environment and when it was last used there. A feature being released gradually, a deliberate off switch for one environment, or a brand new flag is treated as expected rather than reported as drift.

### Does this work on a lower tier LaunchDarkly plan?

Yes. It sticks to reading your flags and their usage, and avoids the approval and scheduled change features that are limited to higher plans.

### Will it open the same ticket over and over?

No. Before creating a ticket it checks whether a matching one was already opened for that flag in the last two weeks, and skips it if so.

Use this prompt in General Input: https://www.generalinput.com/prompts/catch-feature-flags-that-never-got-switched-on-in-production