Inventory four hundred LaunchDarkly flags with last-change dates

Find the flags nobody has touched since March

Listing flags for a project and environment gives you state.

The audit log gives you history. Together they answer the question that makes cleanup possible: which flags have had no recorded change in months, who last touched the ones that did, and which of those still evaluate in production.

Four hundred rows of that is a spreadsheet, and a companion writes it, then drafts the pull request description that removes the eleven safe ones. That is operations work nobody was doing, and pulling flags, segments and audit entries into one reviewable artefact is data extraction with a compliance flavour.

What happens when a companion toggles a flag?

Two gates, protecting different mistakes.

Inside Strawberry the call is consequential, so it waits for your approval with the flag and environment named. On LaunchDarkly’s side, an environment configured to require confirmation and comments routes the same call into its own approval workflow.

Against a staging environment without those guards, the toggle is a single patch replacing the on value for that environment and takes effect immediately after you approve it. Reading the environment’s policy first is a step the companion can take for you.

How precise is a flag patch?

As precise as the path it names.

The update tool accepts either a raw JSON Patch array or LaunchDarkly’s semantic instructions, and the guidance is to prefer JSON Patch unless the semantic form is specifically needed. JSON Patch names the path being replaced, so the approval you see describes an exact change rather than an intention.

Deleting a flag is flagged destructive and confirmed before it runs. A deleted key that code still evaluates falls back to whatever default the SDK was handed, and that default is regularly not the one anyone wanted. Finding those is what the audit is for.

Read flags, segments and the audit log

Flags across projects and environments, segments rule by rule, account members, the audit log, and guarded writes on flags. For most teams that is the right division: the weekly inventory and the cleanup draft happen here, and the environment serving customer traffic keeps its own approval chain untouched.

The boundaries are precise. Experimentation and metrics have no tools. Segments are readable rule by rule and are not writable. Members are listable rather than invitable, teams and custom roles are absent, approval requests are raised inside LaunchDarkly, and webhooks and the relay proxy have no tools here.

Frequently asked questions