# What Is a Feature Flag? The Ops-Friendly Explainer URL: https://formula.dog/journal/what-is-a-feature-flag Type: blog Locale: en Published: 2026-09-19 Updated: 2026-09-19 --- > Feature flags give software teams a runtime switch to enable or disable features without pushing new code. For ops and analytics people, understanding them is surprisingly useful. What is a feature flag? It is a conditional switch in software that turns a specific feature on or off at runtime, without changing the underlying code or pushing a new deployment. Your engineering team ships the code, and the flag decides whether users see it. If you have been in a sprint review and heard the phrase "we are launching behind a flag," now you know exactly what that means. This concept comes up constantly in cross-functional work: product launches, incident reports, A/B test results, and release notes all reference flags. The faster you can parse what a flag is and what state it is in, the more useful you are in those conversations. ## A feature flag is an IF statement your engineering team uses at scale At its core, a feature flag is an IF statement. In Excel, you write `=IF(A2="ON","Show feature","Hide feature")`. In application code, a flag does the same thing: if the flag is true, execute this code path; if not, skip it and run the fallback. The difference is scale and context. A flag in a production application evaluates millions of times per second, across every active user session, with logic that can target specific users, geographies, device types, or percentage cohorts. The underlying concept is identical to what you already use in a spreadsheet. This is not an accident. Feature flags were formalized precisely because developers kept writing the same toggle logic by hand, over and over, in every codebase. The pattern got extracted into dedicated libraries and platforms. The IF statement grew up. ## The four types of feature flags you will encounter at work Feature flags split into four categories. Knowing which type someone is talking about changes the conversation. **Release flags** control whether a new feature is visible to users. They are temporary by design: once the feature is stable and fully rolled out, the flag gets deleted. "The new checkout flow is behind a flag" means it is built and tested but not yet public. The team controls the moment of release independently from the moment of deployment. **Experiment flags** power A/B tests. A percentage of users see version A, the rest see version B, and analytics tools measure the behavioral difference. These flags generate data before a product decision is finalized and avoid the guesswork of "which version is better." **Ops flags** are kill switches. They default to ON, and if something breaks in production, an engineer flips the flag OFF to disable the feature instantly, without waiting for a new deployment to ship. Incident response time drops from 45 minutes to under two minutes. Every serious production system has at least a few of these. **Permission flags** gate features by user tier, account type, region, or any other attribute. Premium users see the advanced reporting dashboard; free users do not. A customer upgrades their plan, and the flag evaluates differently the next time they log in. No code change required. ![Abstract visualization of a software rollout pipeline with green active nodes and grey inactive nodes on a dark background](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/b4d0db-inline2.webp) ## Why ops, analytics, and product teams care about feature flags Feature flags are not just a developer concern. They directly shape the data that ops and analytics teams work with every day. Release management gets more complex when engineering ships code continuously. A single production application can have 30 to 60 active flags at once. If your ops team does not know which features are live, which are in partial rollout, and which have been disabled, you are missing context for every metric you track. Conversion rate drops on a Tuesday morning? The first question should be: did any flags change in the past 24 hours? A new cohort behaves differently than the baseline? Check whether they are inside an experiment group. Attribution looks off? A flag may have silently changed the user flow that your tracking relies on. The people who catch these anomalies first are often in analytics, not engineering. Reading a flag changelog is a baseline skill for anyone who works with product data. ## How feature flag state shows up in your reports When a flag changes state, it creates a discontinuity in your data. This is not a bug; it is expected. But if you do not track it, you will spend hours debugging something that is not a bug at all. The cleanest way to handle this: keep a flag event log alongside your analytics data. Every time a flag is toggled, record the timestamp, the flag name, the previous state, the new state, and who made the change. When you pull a time-series report and see a step change in a metric, you can overlay the flag log to see whether a toggle correlates with the inflection point. In Google Sheets, a simple VLOOKUP against the flag log timestamps gives you this view in about 10 minutes. The formula: `=VLOOKUP(DATE_OF_SPIKE, flag_log!A:E, 3, TRUE)` returns the nearest flag change on or before that date. Not precise, but fast enough to rule out or confirm a hypothesis before escalating. ## How to build a feature flag tracker in Excel or Google Sheets You do not need a dedicated platform to track flag status for a small team. A spreadsheet works well for visibility, coordination, and lightweight auditing. Create a sheet called `flags`. Add these columns: Flag Name | Status | Type | Owner | Last Changed | Notes. For Status, use a real Boolean. In Google Sheets: Format > Checkbox creates a TRUE/FALSE cell. In Excel: use Data Validation to allow TRUE/FALSE, or a dropdown that maps to those values. Do not use the text strings "TRUE" and "FALSE" as plain text; the IF comparisons break. In your reporting sheet, reference the flag table with XLOOKUP (Excel 365 and Google Sheets): `=IF(XLOOKUP("checkout-redesign", flags[Flag Name], flags[Status]), "Active", "Inactive")`Or with VLOOKUP for older Excel versions: `=IF(VLOOKUP("checkout-redesign", flags!A:B, 2, FALSE) = TRUE, "Active", "Inactive")`This lets your reporting sheet react automatically when someone updates the Status column in the flags sheet. Flip a checkbox, and every dependent formula updates. ![Spreadsheet on a laptop screen showing rows of feature data with green and red status indicators in status columns](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/942812-inline1.webp) ## The IF formula pattern at the center of flag logic The base formula is short: `=IF(B2=TRUE, "Feature ON", "Feature OFF")`Where B2 holds the Boolean status of the flag. For a more practical version that cascades across a reporting row, using XLOOKUP to fetch the status by flag name: `=IF(XLOOKUP("flag-name", FlagsTable[Flag Name], FlagsTable[Status]), "[value if active]", "[value if inactive]")`Argument breakdown: - `"flag-name"` is the exact string as it appears in your flags table. - `FlagsTable[Flag Name]` is the lookup column in your named Table. - `FlagsTable[Status]` is the column that returns the Boolean. - The outer IF evaluates the result. One precision point: if you are on a version of Excel before 2019, XLOOKUP does not exist. Use the VLOOKUP version or upgrade to 365. Google Sheets supports XLOOKUP across all versions as of 2024. Another precision point: XLOOKUP with a Boolean Status column returns TRUE or FALSE directly. The IF check `IF(result)` works without `=TRUE` because IF treats TRUE as truthy. But adding `=TRUE` explicitly, as in `IF(XLOOKUP(...)=TRUE, ...)`, makes the intent clearer for anyone reading the formula later. Both work. ## When the spreadsheet is enough and when it is not A spreadsheet flag tracker works when the team is small, the number of active flags is under 20, and the requirement is visibility and coordination, not runtime evaluation. It breaks down in three scenarios. First, when flags need to evaluate for real users in a live application: that requires code reading a flag store at request time, which a spreadsheet cannot do. Second, when you need percentage rollouts, for example serving the new feature to 10% of users: that logic lives in the application layer. Third, when audit and compliance require tamper-proof logs: a shared Google Sheet has no write-level audit trail. For teams that outgrow the spreadsheet, the typical path is: start with an open-source platform like Unleash or Flagsmith (self-hosted, free tier available), then move to a commercial tool like LaunchDarkly or Statsig when scale and integrations justify the cost. ![Top-down view of a whiteboard with sticky notes in two colors organized in on and off columns representing feature flag planning](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-09/8de2fb-inline3.webp) ## Three tools that ops and analytics teams use alongside feature flags Whether you are building the flag tracker or just reading the output, these tools come up regularly in the same workflow. ## Common flag mistakes that create reporting headaches Stale flags are the most frequent problem. A flag created for a temporary test sits in the codebase for a year. Its Status column still says Active, but nobody is sure what it controls anymore, and nobody wants to remove it in case something breaks. The fix is a quarterly flag audit: review every flag that has been in a stable state for more than 60 days. Flags that are fully rolled out to 100% of users with no plans to revert should be removed from the codebase. This is a 30-minute coordination task, not an engineering project. Your spreadsheet tracker is the right place to run it. The second mistake is toggling a flag without recording the change. When a metric shifts on a Thursday afternoon, the immediate question is what changed today. If flag changes are not timestamped and attributed in your tracker, root cause analysis takes hours instead of minutes. The fix is simple: add a Change Log tab. When anyone updates the Status column, they add a row with the date, flag name, old status, new status, their name, and the reason. Two minutes of discipline per change saves two hours of debugging per incident. The formula for making this easy: use Google Sheets with protected ranges and a form-linked row for the log, so the process is hard to skip. The third mistake is giving flags names that do not explain what they do. A flag named `flag_4712` or `test_checkout_v2` tells you nothing in isolation. Flag names should be descriptive: `checkout_new_address_form`, `homepage_personalization_experiment`, `reporting_v3_early_access`. Your future self reading the spreadsheet six months from now will thank you. ## FAQ ### What is a feature flag in simple terms? A feature flag is a conditional switch that turns a software feature on or off at runtime, without changing or redeploying the code behind it. Engineers write the code, and the flag controls whether users see it. ### What is the difference between a feature flag and a feature toggle? They are the same thing. Feature toggle is an older term; feature flag is now more common. Both refer to a runtime control that enables or disables a feature without a code deployment. ### Can I build a feature flag system in Excel or Google Sheets? Yes, for visibility and coordination use cases. A config sheet with TRUE or FALSE values and IF or XLOOKUP formulas in your reporting sheet can replicate the tracking logic. It does not handle runtime evaluation for live application users, but it works well for small teams managing fewer than 20 flags. ### What tools do large teams use for feature flags? LaunchDarkly, Split.io, Statsig, ConfigCat, Unleash, and Flagsmith are the most common. They handle flag evaluation at millisecond speed, percentage-based rollouts, user targeting, and audit logs at scale. ### How are feature flags used in A/B testing? An experiment flag assigns users to different variants at runtime. A percentage of users see the flag-enabled version, the rest see the default. Analytics tools compare behavior between groups. The flag is removed once a winner is declared. ### What is a kill switch and how does it relate to feature flags? A kill switch is an ops flag that defaults to ON. When something breaks in production, an engineer turns it OFF immediately, disabling the broken feature without deploying new code. It is the fastest way to recover from an incident. ### How many active feature flags are too many? There is no fixed number, but unused flags accumulate technical debt and create confusion. Most teams run a quarterly audit and retire flags that have been fully stable for 60 to 90 days. A well-maintained spreadsheet tracker makes this audit straightforward.