LaunchDarkly Flag Change Watchdog

Most flag changes are fine and one of them is the whole incident, and the difference usually sits in an audit log nobody reads. This agent watches account activity, ignores everything that is not a flag change, and posts three lines to Slack: who changed what, before and after, and why your policy says it matters, plus a risk line when the policy is explicit about it. It cannot flip anything back, which is the design, because the person who owns the rollout should be the one making that call.

What people use it for

• Production changes get a witness - A rollout going from a quarter of traffic to everyone is announced in the channel as it happens, with the changer, the environment and the numbers, so a release is visible to people who were not in that browser tab.
• Kill switches treated as such - Turning targeting off on a fraud hold or a rate limiter looks tiny in an audit log and enormous an hour later. Naming those flags in your policy earns them an explicit risk line and a person to confirm it.
• Flags untouched for a year - The flag's own status comes back with the change, so a permanent flag last modified fourteen months ago is called out as exactly that instead of reading like routine housekeeping.
• Staging noise stays in staging - The environment key is read off the audit entry rather than assumed, so a dozen experiments a day on a shared staging box never reach a channel that exists to watch production.

Before you fork

Can it roll a flag back if someone breaks production?

No, and it is built that way on purpose. It reads flags, flag status and the audit log, and it writes only to Slack. A rollback is a production change with its own approval path, and an agent reading one audit entry does not have the context to make it. What it gives you instead is the change and the named owner within seconds of it happening.

Our team changes flags all day. Will this be constant noise?

It reacts to flag changes only, and how loud those get is set by the policy you write, so protected environments and named kill switches produce a message while routine work in lower environments does not. Everything it drops is dropped silently. If the channel is still busier than you want, tighten the policy rather than the trigger.

What LaunchDarkly access does it need?

A reader level API token that can read flags, flag status and the audit log, plus the Slack channel for the notes. No writer or admin role is required, and granting one would add risk without adding a capability. Your flag policy is filled in during fork, and can be edited any time after.