Product feature
Feature flag audit log
Every change to a flag, recorded automatically. Who made it, what moved from and to, and when, so a release that goes wrong turns into a specific, attributable fact instead of a guess.
Last updated:
Featureflip records every change to your flags and configuration automatically, with nothing to enable. Each entry captures who made the change, what changed, and when, and for an edit it stores each property's previous and new value. You can read the log organization-wide, filtered by project, entity, action, user, and date, or open a single flag's History tab for a complete timeline of that flag. History is retained from 7 days on the free plan up to 365 days on Enterprise.
What the audit log gives you
A complete, automatic record of every change, detailed enough to answer "what changed, and who changed it" during an incident or a compliance review.
Every change, recorded automatically
There is nothing to switch on. From the moment you start using Featureflip, every create, update, and delete across your flags and configuration is captured, so when something breaks you can answer what changed and who changed it without guesswork.
Who, what, and when
Each entry stores the actor's name and email, a precise timestamp, and the request's IP address and user agent. The actor is preserved on the entry even if that person later leaves your team, so the record stays complete for a later review.
Before and after on every edit
For an update, each changed property is recorded on its own with its previous value and its new value. You see exactly what moved, a rollout going from 25% to 100% or a flag flipping from enabled to disabled, not just that something changed.
Everything that drives a flag
The log covers feature flags, variations, targeting rules, per-environment configuration, environments, user segments, SDK keys, projects, and the organization itself. If a change can affect how a flag behaves, that change is on the record.
Two ways to read it
The organization-wide Audit Log page lists every change newest first, filterable by project, entity or entity type, action, user, and date range. Each flag also has a History tab with a complete timeline for that one flag, including its variations, per-environment config, and rules.
Retention by plan
History is kept for 7 days on Solo, 30 on Pro, 90 on Business, and 365 on Enterprise, and entries past your window are removed automatically. Flat pricing means the log is never metered by how many changes your team makes.
For the full list of recorded entities, the filters, and the retention policy, see the audit log documentation.
What a single entry captures
An entry is more than "someone edited a flag." It names the actor, the exact property that changed, and both values, so you can act on it directly. A rollout bump looks like this:
new-checkoutinProductionrolloutPercentage25%100%by Jordan Lee (jordan@acme.example) · July 3, 2026 at 14:12 UTC · 203.0.113.7
Every entry carries the same shape: the action (created, updated, or deleted), the entity it touched, the changed property with its before and after values, the actor, a timestamp, and the request's IP address and user agent. The actor is kept on the entry even if that person later leaves the team.
Reconstructing an incident, step by step
When a release goes wrong, the audit log turns "something changed" into a change you can name and undo.
- 1
Notice behavior shifted
A release starts misbehaving and you need to know what changed. Rather than guessing, open the affected flag in the Featureflip dashboard.
- 2
Open the flag's History tab
The History tab shows a complete timeline for that flag and everything beneath it: its variations, its per-environment configuration, and its targeting rules. Filter by action and date range to narrow the window you care about.
- 3
Find the change that lines up
Look for the entry whose timestamp matches when behavior shifted, a toggle, a rollout bump, or a rule edit. Because the timeline is newest first, the change that broke things is usually near the top.
- 4
Read before and after, then act
Confirm what actually changed from the previous and new values, and who changed it. Pair that with a kill switch to turn the feature off in seconds, then keep the record for the post-incident review.
The audit log is one half of incident response and the kill switch is the other: turn the feature off in seconds, then keep the record of who turned it on and when for the review afterward.
The audit log sits under every change
Because the log records the entities that drive flag behavior, every other capability leaves a trail without any extra step:
- Targeting edits are recorded. Adding, reordering, or changing a rule, and creating or editing a segment, all appear on the record with their before and after values.
- Rollout moves are recorded. Every percentage change is captured, so you can see who moved a ramp to what, and when, alongside the rest of the flag's history.
- Per-environment changes are attributed. A toggle or configuration change is logged against the specific environment it happened in, so production changes stand apart from staging.
- Security-relevant actions are covered. Creating, rotating, or revoking an SDK key is on the record too, so key changes are as auditable as flag changes.
The actors on those entries come from your team members and their roles, and the whole record is delivered by the same platform your app already evaluates against.
Frequently asked questions
- Does Featureflip log who changed a feature flag?
- Yes. Featureflip records every change automatically, with no configuration required. Each audit entry captures who made the change (name and email), what changed (the entity, and for edits the specific property with its before and after values), and when it happened, along with the request's IP address and user agent. Toggling a flag, editing a targeting rule, changing an environment configuration, creating or deleting a segment, and rotating an SDK key are all recorded. You can review the log organization-wide or scoped to a single flag from the dashboard.
- What changes are recorded in the audit log?
- Featureflip records create, update, and delete actions across feature flags, variations, targeting rules, per-environment flag configurations, environments, user segments, SDK keys, projects, and the organization itself. For updates, each changed property is recorded individually with its previous and new value. Each entry also stores the actor, a timestamp, and request metadata such as IP address and user agent, so the record covers not just flags but everything that shapes how they evaluate.
- Can I see the full history of a single feature flag?
- Yes. Every flag has a History tab that shows a complete timeline for that flag, including changes to the flag itself and to everything beneath it: its variations, its per-environment configuration, and its targeting rules. During an incident this is usually the fastest way to answer who changed this flag and when, without scrolling the organization-wide log. The per-flag history can be filtered by action and date range.
- How long does Featureflip keep audit logs?
- Audit log retention depends on your plan: 7 days on Solo, 30 days on Pro, 90 days on Business, and 365 days on Enterprise. Entries older than your retention window are removed automatically. If you need to keep records longer, for a compliance review or a post-incident archive, move to a plan with a longer window. Because Featureflip uses flat pricing, the audit log is not billed by the number of changes you make.
- Does the audit log capture the old and new values of a change?
- Yes. When a property is updated, Featureflip records it individually with both its previous value and its new value, so you can see exactly what moved rather than only that an edit happened. For example, a rollout entry shows the percentage going from 25% to 100%, and a toggle entry shows the state going from enabled to disabled. That before-and-after detail is what turns a vague sense that something changed into a specific, attributable fact.
- Can I filter or search the audit log?
- Yes. The organization-wide Audit Log page can be filtered by project, by entity or entity type such as a specific flag or segment, by action (created, updated, deleted), by user, and by date range, and results are paginated so a busy project stays navigable. The per-flag History tab adds action and date-range filters focused on one flag. Between the two views you can move from a broad organization-wide search down to the exact change on a single flag.
Know who changed what, and when
Audit logging is automatic on every plan, including the free Solo tier with a 7-day window. Paid plans extend retention to 30, 90, or 365 days, on flat pricing with no per-seat fees.
Related
Audit log (docs)
What gets recorded, the two views and their filters, retention by plan, and the incident-review workflow.
Team management (guide)
Invite members and manage roles, the actors that show up on every audit entry.
Environments (feature)
Per-environment configuration changes are attributed to the environment they happened in.
Kill switch (use case)
Turn a feature off fast, then read the record of who turned it on and when.