Track every half finished LaunchDarkly rollout in one board

I want a rollout control room that I open every morning as the release manager, so I can see every LaunchDarkly feature flag that is currently stuck partway through a rollout. Build it as an app with one main board. Nothing runs on a schedule and nothing changes a flag on its own, because a person decides every ramp.

The board lists one card per flag that is on but not fully rolled out, meaning the flag is enabled in at least one environment and its targeting still serves a percentage rollout rather than a single variation to everybody. Pull these with List feature flags, requesting per environment configuration so each record carries the rollout percentage and the variations for every environment.

Each card shows whether the flag is actually being evaluated, using List feature flag statuses, so I can tell a live 25 percent rollout apart from one that no traffic is hitting. The card also shows who last touched the flag and how many days it has sat at its current percentage. Work that out from List audit log entries by finding the most recent entry that changed the rollout percentage for that flag and measuring from that entry's date to now.

Show every environment side by side on the card, one column per environment with its own on and off state, rollout percentage and variation split. Staging drifting away from production should be obvious at a glance without opening anything.

When a Linear ticket id sits in the flag description or in one of its tags, pull that ticket through Get Issue and show its current state and assignee on the card, so I can see whether the work behind the rollout is even still open.

From a card I can ramp to the next stage, hold, or turn the flag off. Treat the ramp stages as 1, 5, 10, 25, 50, 75 and 100 percent, and let me confirm or edit the target percentage before anything submits. Ramp and turn off both write back with Update feature flag using a semantic patch against the environment I picked. Hold does not touch LaunchDarkly at all, it records a deliberate pause so the card reads as intentional rather than forgotten.

Every one of those three actions requires me to type a one line reason before it will submit. Once the change lands, post the flag, the environment, what changed and my reason to the release channel with Slack Send a Message, so the team gets a running record of who decided what.

Add a Check rollout health button on each card that runs a background agent against that one flag. The agent takes the timestamp of the last ramp from the audit history, then pulls Sentry List Organization Issues and Retrieve Event Counts for a Project for the window since that ramp, and compares error volume in the window after the ramp against an equally long window before it. It also scans recent audit entries for the same flag for competing changes, meaning other people moving the same flag inside the same window. It finishes by writing a ramp, hold or roll back recommendation back onto the card, along with its evidence: the before and after error numbers, the issues that grew most, and any competing changes it found. The recommendation is advice only and never changes the flag.

Sort the board by days stuck at the current percentage, longest first, so a forgotten 25 percent rollout from three weeks ago floats to the top. Never auto ramp anything and never run the health agent on a schedule. A person presses the button.

LaunchDarkly API notes for whoever builds this. The token goes in the Authorization header raw with no Bearer prefix. Send LD-API-Version: 20240415 on every request. Address everything by key rather than id, so projectKey, environmentKey and featureFlagKey. Semantic patch needs Content-Type: application/json; domain-model=launchdarkly.semanticpatch with a body shaped like {"environmentKey":"production","instructions":[{"kind":"turnFlagOff"}]}. Take the API host from the region field on the credential, since commercial, EU and federal accounts each answer on their own host. Responses are HAL style with an items array plus a _links.next href for pagination. The audit log is the awkward one: it pages backwards, caps at 20 items per page, and you fetch older pages by setting before to the date of the oldest entry you received, in epoch milliseconds.

One framing note. This app is the proactive daily surface for rollouts already in flight, and it complements the existing reactive workflow that fires on a Sentry alert to find which flag caused a spike. The difference is that here I choose the flag and the window and press the button myself, rather than chasing an alert after something has broken.