Track feature flag changes, next to everything else that moved

A feature flag exists for exactly one reason: to change how production behaves without shipping code. That is what makes it useful, and it is also what makes it the most likely cause of a change your deploy log cannot explain.

A rollout that moved from 50% to 100% over a weekend is not a deploy. It is not in your git history. It is very much a change, and for the customers who crossed that boundary it is the only thing that happened.

What your flag tool already gives you

A complete and well-attributed record of what happened inside it. LaunchDarkly, Statsig, PostHog and the rest all keep an audit log with who changed which flag, when, and to what. If you know a flag is the suspect, that is the authoritative source and you should start there.

Two things it is not built to do:

• Read as one timeline with everything else.The log is organised per flag and shaped for the people who administer flags. “Show me everything anyone changed on Tuesday afternoon, in order” is not the question it answers.
• Know about anything outside itself. It cannot tell you the rollout landed the same afternoon as a price change in Stripe and a republished pricing page. That adjacency is usually the actual answer, and no single tool can see it.

The four flag changes that cause the most confusion

• A percentage rollout crossing a threshold. Nobody edited it that day. It was scheduled, or someone nudged it a week ago and the effect only became visible when the sample got big enough to see in a chart.
• A targeting rule change.The flag is still “on”, but who it is on for changed. A segment, a country, a plan tier. Trivially easy to miss because the headline state looks identical.
• A kill switch left flipped. Someone disabled a feature during an incident, the incident resolved, and nobody turned it back on. The metric never fully recovers and nobody knows why.
• A stale flag nobody owns. The experiment ended months ago. The flag is still evaluating, still branching, and the person who created it has left.

What you actually want to see

The useful artifact is boring: one list, in time order, of every production-affecting change across every tool, with flag changes in it.

• 4:02pm — LaunchDarkly: new-checkout 50% → 100%
• 2:14pm — Stripe: Pro monthly price changed $49 → $59
• 12:40pm — CMS: pricing page republished

Nothing there is clever. The value is entirely in the adjacency: three defensible, unrelated changes that together explain a conversion drop nobody could account for, sitting in one place instead of three dashboards.

Practical habits, whether or not you use a tool

• Put the flag key in the change, not just the ticket. A timeline entry you can search for by key is worth ten you can only find by date.
• Give every flag an owner and an expiry at creation. Stale flags are the ones that cause the confusing incidents, because nobody remembers they exist.
• Record the intent, not only the value.“50 → 100 because the error rate held for a week” is worth far more in three weeks than true.

Where Rearview fits

Rearview pulls flag changes onto the same timeline as your billing changes, CMS publishes, storefront edits and deploys, and lets anyone on the team ask it in plain English. It is built for the person who gets asked what happened and does not have an account in your flag tool.

Related reading: when somebody changed something and nobody wrote it down, tracking Stripe pricing changes, and why a clean deploy log is not a quiet week.