Article

Feature Flags and Toggles in .NET

Q: What is a feature flag?

A feature flag (also called a feature toggle or feature switch) is a runtime switch that enables or disables a code path without redeploying. Used for gradual rollouts, A/B testing, and kill switches.

Q: What is a feature filter?

A feature filter decides when a flag is on (e.g. percentage of users, specific user list, time window). Combine filters (e.g. 10% AND after date X) for fine control. Built-in filters: PercentageFilter, TimeWindowFilter, TargetingFilter.

Q: How do I add feature flags to ASP.NET Core?

Install Microsoft.FeatureManagement.AspNetCore, then call builder.Services.AddFeatureManagement() in Program.cs. Check flags with await _featureManager.IsEnabledAsync("FeatureName") in controllers or services. Add filters (e.g. .AddFeatureFilter ()) for conditional enablement.

Q: What is Azure App Configuration for feature flags?

Azure App Configuration is a managed service that stores feature flags and key-value config in Azure. Your app fetches on startup or subscribes to refresh; use labels for per-environment values (dev, staging, prod). Supports Managed Identity for secure access.

Q: How do I do a gradual rollout with feature flags?

Use a percentage filter (e.g. "Value": 10 for 10% of requests). Increase the percentage over time (25%, 50%, 100%). If issues appear, reduce to 0% as a kill switch without redeploying. Monitor metrics (errors, latency) at each stage.

Q: Should I evaluate feature flags on the client or server?

Evaluate server-side only for security and consistency. Client-side flags can be tampered with and expose rollout logic. For SPAs or mobile apps, call an API that returns "is feature X enabled for this user?" rather than sending flag state to the client.

Q: What is a kill switch?

A kill switch is the ability to turn off a feature instantly without redeploying. With feature flags, set the flag to false (or percentage to 0) in Azure App Configuration so that all users revert to the old code path. Use when the new feature causes incidents.

Q: How do I do A/B testing with feature flags?

Use a percentage filter (e.g. 50%) to assign users to A (old) or B (new). Track metrics (conversion, latency) for each variant. Use consistent assignment (hash user ID) so each user sees the same variant every time. After 1-2 weeks, pick the winner and retire the flag.

Q: What is flag sprawl and how do I avoid it?

Flag sprawl is when too many feature flags are never retired, leaving the codebase full of dead branches. Avoid by retiring release toggles within 3 months of full rollout. Add a "created date" to each flag and review monthly. Only ops and permission toggles should be long-lived.

Feature flags in .NET: IFeatureManager, Azure App Configuration, and safe rollouts.

January 30, 2025 · Waqas Ahmad

Read the article

Introduction

This guidance is relevant when the topic of this article applies to your system or design choices; it breaks down when constraints or context differ. I’ve applied it in real projects and refined the takeaways over time (as of 2026).

Deploying and releasing in one step risks bad rollouts and no way to turn off a problematic feature without a new release. This article covers feature flags in .NET: what they are, Microsoft.FeatureManagement and Azure App Configuration, filtering (percentage, user, time window), gradual rollout, A/B testing, kill switches, and retiring flags. For architects and tech leads, flags enable deploy-without-release and safe rollouts; using them with a clear lifecycle and server-side evaluation keeps production under control.

For a deeper overview of this topic, explore the full .NET Architecture guide.

Decision Context

System scale: Single app to many services; teams that deploy frequently and need to control rollout or kill features without redeploy. Applies when you want to decouple deploy from release.
Team size: Dev and ops (or platform); someone must own flag definitions, storage, and retirement. Works when the team will actually retire flags (otherwise flag sprawl grows).
Time / budget pressure: Fits when you’re doing gradual rollouts or A/B tests; breaks down when there’s no process to turn flags off or retire them—then flags become technical debt.
Technical constraints: .NET with Microsoft.FeatureManagement; Azure App Configuration or other store; server-side evaluation for consistency. Assumes you can cache and refresh flag state.
Non-goals: This article does not optimise for client-side-only flags or for non-.NET stacks; it focuses on ASP.NET Core and Azure App Configuration.

What is a feature flag?

A feature flag (also called a feature toggle or feature switch) is a runtime switch that turns a piece of functionality on or off without redeploying the application. Think of it as an if statement whose condition is controlled by configuration, not code.

For example, instead of deploying a new checkout flow and hoping it works for everyone, you deploy the code behind a flag and enable it only when ready. You can enable it for 10% of users first, then 50%, then 100%. If something breaks, you turn the flag off (a kill switch) and all users revert to the old flow—no hotfix deploy required.

Feature flags are evaluated at runtime (per request or per user), so you can change behaviour without a new release. In .NET, you typically use Microsoft.FeatureManagement (IFeatureManager) and store flag state in Azure App Configuration, a database, or a simple config file.

Why use feature flags?

Use case	Description	Example
Gradual rollout	Enable for a small percentage of users first, then increase	Roll out new payment flow to 10%, then 50%, then 100%
A/B testing	Run two code paths and measure which performs better	Compare old vs new homepage; measure conversion rate
Kill switch	Turn off a feature instantly if it causes issues	New search breaks production; disable it without redeploying
Trunk-based development	Merge incomplete features to main without exposing them	Feature is behind a flag (off); developers merge daily
Canary releases	Enable for internal users or beta testers first	Enable for employees; test in prod before public launch
Operational toggles	Enable/disable expensive features during high load	Turn off analytics during Black Friday to save resources

Feature flag types

Feature flags fall into different categories based on their purpose and lifespan:

Type	Lifespan	Purpose	Example
Release toggles	Short (days to weeks)	Hide incomplete features until ready	New checkout flow behind `NewCheckout` flag
Experiment toggles	Short to medium (weeks)	A/B testing and experiments	`RecommendationAlgorithmV2` for 50% of users
Ops toggles	Long-lived	Operational control (turn off expensive features)	`EnableDetailedLogging`, `EnableCaching`
Permission toggles	Long-lived	Premium features or role-based access	`PremiumFeatures` for paid users only

Important: Release and experiment toggles should be retired (removed from code) once the feature is stable or the experiment concludes. Ops and permission toggles are long-lived by design.

Adding feature flags to ASP.NET Core

To add feature flags to an ASP.NET Core application, use the Microsoft.FeatureManagement.AspNetCore NuGet package. This provides IFeatureManager for checking flags and built-in filters for common scenarios.

Step 1: Install the package

dotnet add package Microsoft.FeatureManagement.AspNetCore

Step 2: Register feature management in Program.cs

// Program.cs – register FeatureManagement
using Microsoft.FeatureManagement;

var builder = WebApplication.CreateBuilder(args);

// Add feature management with filters
builder.Services.AddFeatureManagement()
    .AddFeatureFilter<PercentageFilter>()
    .AddFeatureFilter<TimeWindowFilter>()
    .AddFeatureFilter<TargetingFilter>();

builder.Services.AddControllers();

var app = builder.Build();
app.MapControllers();
app.Run();

Step 3: Configure flags in appsettings.json

{
  "FeatureManagement": {
    "NewCheckout": true,
    "BetaFeatures": {
      "EnabledFor": [
        {
          "Name": "Percentage",
          "Parameters": {
            "Value": 10
          }
        }
      ]
    },
    "SeasonalPromo": {
      "EnabledFor": [
        {
          "Name": "TimeWindow",
          "Parameters": {
            "Start": "2026-12-01T00:00:00Z",
            "End": "2026-12-31T23:59:59Z"
          }
        }
      ]
    }
  }
}

Step 4: Check flags in code

// OrdersController.cs – branch on feature flag
using Microsoft.FeatureManagement;

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IFeatureManager _featureManager;
    private readonly IOrderService _orderService;

    public OrdersController(IFeatureManager featureManager, IOrderService orderService)
    {
        _featureManager = featureManager;
        _orderService = orderService;
    }

    [HttpPost("checkout")]
    public async Task<IActionResult> Checkout([FromBody] CheckoutRequest request)
    {
        // Check if new checkout flow is enabled
        if (await _featureManager.IsEnabledAsync("NewCheckout"))
        {
            return await NewCheckoutFlow(request);
        }
        
        // Fall back to legacy flow
        return await LegacyCheckoutFlow(request);
    }

    private async Task<IActionResult> NewCheckoutFlow(CheckoutRequest request)
    {
        var result = await _orderService.ProcessCheckoutV2Async(request);
        return Ok(result);
    }

    private async Task<IActionResult> LegacyCheckoutFlow(CheckoutRequest request)
    {
        var result = await _orderService.ProcessCheckoutV1Async(request);
        return Ok(result);
    }
}

Step 5: Use FeatureGate attribute (optional)

For MVC/Razor Pages, use [FeatureGate("FeatureName")] to hide entire actions or pages:

// Only accessible if BetaFeatures flag is enabled
[FeatureGate("BetaFeatures")]
[HttpGet("beta-dashboard")]
public IActionResult BetaDashboard()
{
    return View();
}

Feature filters: percentage, user, time window

Feature filters decide when a flag is enabled. Instead of a simple on/off, filters let you enable for a percentage of users, specific users, or during a time window.

Built-in filters

Filter	Purpose	Configuration
PercentageFilter	Enable for X% of requests	`"Value": 10` (10% of requests)
TimeWindowFilter	Enable during a time range	`"Start"`, `"End"` (ISO 8601 dates)
TargetingFilter	Enable for specific users/groups	`"Audience"` with user/group lists

PercentageFilter example

Enable for 25% of requests (stateless; each request has 25% chance):

{
  "FeatureManagement": {
    "NewRecommendations": {
      "EnabledFor": [
        {
          "Name": "Percentage",
          "Parameters": {
            "Value": 25
          }
        }
      ]
    }
  }
}

TimeWindowFilter example

Enable only during December 2026:

{
  "FeatureManagement": {
    "HolidaySale": {
      "EnabledFor": [
        {
          "Name": "TimeWindow",
          "Parameters": {
            "Start": "2026-12-01T00:00:00Z",
            "End": "2026-12-31T23:59:59Z"
          }
        }
      ]
    }
  }
}

TargetingFilter example

Enable for specific users or groups (e.g. beta testers):

{
  "FeatureManagement": {
    "PremiumDashboard": {
      "EnabledFor": [
        {
          "Name": "Targeting",
          "Parameters": {
            "Audience": {
              "Users": [
                "user1@example.com",
                "user2@example.com"
              ],
              "Groups": [
                {
                  "Name": "BetaTesters",
                  "RolloutPercentage": 100
                }
              ],
              "DefaultRolloutPercentage": 0
            }
          }
        }
      ]
    }
  }
}

Custom filters

Create a custom filter by implementing IFeatureFilter:

// Custom filter: enable only for requests from specific IP range
using Microsoft.FeatureManagement;

public class IpRangeFilter : IFeatureFilter
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public IpRangeFilter(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        var ipAddress = _httpContextAccessor.HttpContext?.Connection.RemoteIpAddress?.ToString();
        var allowedRange = context.Parameters.Get<string>("AllowedRange");
        
        // Simple check (production: use proper IP range parsing)
        var isAllowed = ipAddress?.StartsWith(allowedRange) ?? false;
        return Task.FromResult(isAllowed);
    }
}

// Register in Program.cs
builder.Services.AddFeatureManagement()
    .AddFeatureFilter<IpRangeFilter>();

{
  "FeatureManagement": {
    "InternalTools": {
      "EnabledFor": [
        {
          "Name": "IpRange",
          "Parameters": {
            "AllowedRange": "10.0.0"
          }
        }
      ]
    }
  }
}

Azure App Configuration integration

Azure App Configuration is a managed service that stores feature flags (and other config) in Azure. Your app fetches flags on startup or subscribes to refresh (polling or push) so that toggles update without restarting the app.

Why use Azure App Configuration?

Benefit	Description
Centralised config	One place for all environments (dev, staging, prod)
Dynamic refresh	Change flags without redeploying or restarting
Labels	Per-environment values (dev can have different flags than prod)
Managed Identity	Secure access without connection strings in code
Audit trail	See who changed what and when

Setup: connect ASP.NET Core to Azure App Configuration

dotnet add package Microsoft.Azure.AppConfiguration.AspNetCore
dotnet add package Microsoft.FeatureManagement.AspNetCore

// Program.cs – connect to Azure App Configuration
using Microsoft.Extensions.Configuration.AzureAppConfiguration;

var builder = WebApplication.CreateBuilder(args);

// Connect to Azure App Configuration
builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(builder.Configuration["AppConfig:Endpoint"])
        .Select(KeyFilter.Any, LabelFilter.Null)
        .Select(KeyFilter.Any, builder.Environment.EnvironmentName)
        .UseFeatureFlags(featureFlagOptions =>
        {
            featureFlagOptions.CacheExpirationInterval = TimeSpan.FromSeconds(30);
        });
});

// Add feature management
builder.Services.AddFeatureManagement();

// Add Azure App Configuration refresh middleware
builder.Services.AddAzureAppConfiguration();

var app = builder.Build();

// Use refresh middleware so flags update without restart
app.UseAzureAppConfiguration();

app.MapControllers();
app.Run();

Using Managed Identity (recommended for production)

// Program.cs – Managed Identity for App Configuration
builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri(builder.Configuration["AppConfig:Endpoint"]), new DefaultAzureCredential())
        .Select(KeyFilter.Any, builder.Environment.EnvironmentName)
        .UseFeatureFlags();
});

Labels for per-environment flags

In Azure App Configuration, use labels to have different flag values per environment:

Label: dev → NewCheckout = true (always on for dev)
Label: staging → NewCheckout = 50% (gradual rollout in staging)
Label: prod → NewCheckout = 10% (cautious rollout in prod)

The app selects the label matching builder.Environment.EnvironmentName (Development, Staging, Production).

Dynamic refresh

With UseAzureAppConfiguration() middleware, the app polls Azure App Configuration every 30 seconds (configurable via CacheExpirationInterval). When a flag changes in Azure, the app picks it up without restarting.

// Refresh every 10 seconds (for faster feedback in dev/staging)
featureFlagOptions.CacheExpirationInterval = TimeSpan.FromSeconds(10);

Gradual rollout and A/B testing

Gradual rollout

A gradual rollout means enabling a feature for a small percentage of users first, then increasing over time. This reduces risk: if the feature breaks, only a small fraction of users are affected.

Example rollout plan:

Stage	Percentage	Duration	Action
1. Internal	0% (manual enable for employees)	1 day	Test in prod with real data
2. Canary	5%	2 days	Monitor errors, latency, conversion
3. Ramp	25%	2 days	Increase if metrics are good
4. Majority	50%	2 days	Confidence check
5. Full	100%	Permanent	Remove flag after 1 week of stability

Implementation:

{
  "FeatureManagement": {
    "NewCheckout": {
      "EnabledFor": [
        {
          "Name": "Percentage",
          "Parameters": {
            "Value": 5
          }
        }
      ]
    }
  }
}

Change "Value" in Azure App Configuration (or appsettings.json) to 25, 50, 100 as you progress through stages.

A/B testing

A/B testing (also called split testing) means running two versions of a feature (A = old, B = new) and measuring which performs better. Use feature flags to assign users to A or B, then compare metrics (conversion rate, latency, revenue).

// OrdersController.cs – A/B test: old vs new recommendation algorithm
[HttpGet("recommendations")]
public async Task<IActionResult> GetRecommendations()
{
    if (await _featureManager.IsEnabledAsync("NewRecommendationAlgorithm"))
    {
        // Variant B: new algorithm
        var recommendations = await _recommendationService.GetRecommendationsV2Async(User.Id);
        _telemetry.TrackEvent("RecommendationVariant", new { Variant = "B", UserId = User.Id });
        return Ok(recommendations);
    }
    else
    {
        // Variant A: old algorithm
        var recommendations = await _recommendationService.GetRecommendationsV1Async(User.Id);
        _telemetry.TrackEvent("RecommendationVariant", new { Variant = "A", UserId = User.Id });
        return Ok(recommendations);
    }
}

Measure: Track conversion (did user click/buy?), latency (which is faster?), and user satisfaction (NPS, feedback). After 1-2 weeks, pick the winner and retire the flag.

Sticky assignment (consistent user experience)

For A/B testing, you want each user to see the same variant every time (not flip between A and B). Use TargetingFilter with a consistent user ID:

// Custom filter: consistent assignment based on user ID hash
public class ConsistentPercentageFilter : IFeatureFilter
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public ConsistentPercentageFilter(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        var userId = _httpContextAccessor.HttpContext?.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        if (string.IsNullOrEmpty(userId)) return Task.FromResult(false);

        var percentage = context.Parameters.Get<int>("Value");
        var hash = Math.Abs(userId.GetHashCode()) % 100;
        return Task.FromResult(hash < percentage);
    }
}

builder.Services.AddFeatureManagement()
    .AddFeatureFilter<ConsistentPercentageFilter>();

{
  "FeatureManagement": {
    "NewRecommendationAlgorithm": {
      "EnabledFor": [
        {
          "Name": "ConsistentPercentage",
          "Parameters": {
            "Value": 50
          }
        }
      ]
    }
  }
}

Now each user sees the same variant every time (user ID hash determines A or B).

Kill switches and incident response

A kill switch is the ability to turn off a feature instantly without redeploying. When a new feature causes incidents (errors, performance issues, data corruption), you set the flag to false (or reduce percentage to 0) and all users revert to the old code path.

Example incident response

Scenario: New payment flow causes 5xx errors.

Detect: Monitoring alerts on increased 500 errors.
Investigate: Logs show errors in ProcessPaymentV2Async.
Kill switch: Set NewPaymentFlow = false in Azure App Configuration.
Verify: Errors drop to zero; users use old payment flow.
Fix: Deploy hotfix; re-enable flag after testing.

Code:

[HttpPost("payment")]
public async Task<IActionResult> ProcessPayment([FromBody] PaymentRequest request)
{
    if (await _featureManager.IsEnabledAsync("NewPaymentFlow"))
    {
        try
        {
            return await ProcessPaymentV2Async(request);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "NewPaymentFlow failed; falling back to V1");
            // Optional: auto-fallback on error
            return await ProcessPaymentV1Async(request);
        }
    }
    
    return await ProcessPaymentV1Async(request);
}

Best practice: Always have a fallback path. If the new flow throws, catch and fall back to the old flow (or return a safe error).

Feature flag lifecycle and retirement

Feature flags have a lifecycle: create → enable → measure → retire. Flags that stay in code forever create flag sprawl (hundreds of dead flags, confusing codebase).

Lifecycle stages

Stage	Action	Example
1. Create	Add flag to config and code	`NewCheckout = false` (off by default)
2. Enable	Gradual rollout (5% → 50% → 100%)	Monitor metrics at each stage
3. Measure	Collect data (errors, latency, conversion)	After 1 week at 100%, no issues
4. Retire	Remove flag from code; delete from config	Always use new path; delete old path

How to retire a flag

Step 1: Ensure the flag is at 100% and stable (no errors, good metrics) for at least 1 week.

Step 2: Remove the flag check from code (always use the new path):

// Before (with flag)
if (await _featureManager.IsEnabledAsync("NewCheckout"))
    return await NewCheckoutFlow();
return await LegacyCheckoutFlow();

// After (flag retired)
return await NewCheckoutFlow();

Step 3: Delete the old code path (LegacyCheckoutFlow).

Step 4: Delete the flag from appsettings.json or Azure App Configuration.

Step 5: Deploy and verify.

When to retire

Flag type	Retire when
Release toggle	Feature is at 100% and stable for 1+ week
Experiment toggle	Experiment concludes; winning variant is chosen
Ops toggle	Never (long-lived by design)
Permission toggle	Never (long-lived by design)

Tip: Add a “created date” comment or metadata to each flag so you know how old it is. Flags older than 3 months (for release toggles) are candidates for retirement.

Enterprise best practices

1. Treat feature flags as technical debt. Release toggles should be short-lived (days to weeks). Add a “created date” to each flag and review monthly. Flags older than 3 months are candidates for retirement.

2. Separate flag types. Use naming conventions to distinguish release toggles (Release_NewCheckout), experiment toggles (Experiment_RecommendationV2), ops toggles (Ops_DetailedLogging), and permission toggles (Premium_Dashboard). This makes it clear which flags are temporary and which are permanent.

3. Evaluate flags server-side only. Do not send flag state to the client (SPA, mobile app) unless necessary. Client-side flags can be tampered with and expose rollout logic. For client behaviour, call an API that returns “is feature X enabled for this user?”

4. Use Azure App Configuration (or similar) for production. Do not store production flag values in appsettings.json in source control. Use Azure App Configuration with Managed Identity so that flags can be changed without redeploying and are not committed to Git.

5. Log flag evaluations. Log when a flag is checked and its result (enabled/disabled) so that you can audit rollout and debug issues. Include user ID, flag name, and result in telemetry.

// Log flag evaluation for audit and debugging
var isEnabled = await _featureManager.IsEnabledAsync("NewCheckout");
_logger.LogInformation("FeatureFlag evaluated: {FlagName} = {IsEnabled} for user {UserId}", 
    "NewCheckout", isEnabled, _currentUser.Id);

6. Test both code paths. Write unit and integration tests for both flag on and flag off. This ensures that removing the flag later (and deleting the old path) does not break anything.

// Unit test: test both paths
[Fact]
public async Task Checkout_WithNewFlow_ReturnsV2Result()
{
    _featureManagerMock.Setup(x => x.IsEnabledAsync("NewCheckout")).ReturnsAsync(true);
    var result = await _controller.Checkout(new CheckoutRequest());
    // Assert V2 behaviour
}

[Fact]
public async Task Checkout_WithLegacyFlow_ReturnsV1Result()
{
    _featureManagerMock.Setup(x => x.IsEnabledAsync("NewCheckout")).ReturnsAsync(false);
    var result = await _controller.Checkout(new CheckoutRequest());
    // Assert V1 behaviour
}

7. Use circuit breakers for new code paths. If the new flow is risky (external API, new algorithm), add a circuit breaker so that repeated failures automatically fall back to the old path.

8. Document rollout plans. For major features, write a rollout plan: stages (5%, 25%, 50%, 100%), success criteria (error rate, latency), and rollback procedure (set flag to false). Share with the team so everyone knows the plan.

Common issues and challenges

Issue	Description	Mitigation
Flag sprawl	Too many flags never removed; codebase full of dead branches	Retire flags when feature is stable; review monthly
Stale cache	Flag change in config does not apply immediately	Use refresh (e.g. `CacheExpirationInterval = 30s`) or webhook
Inconsistent user experience	User sees feature on one request, off on next (stateless percentage)	Use consistent assignment (hash user ID) for A/B tests
Security leak	Client-side flags expose rollout logic or can be tampered with	Evaluate server-side only; return “is enabled” from API
Testing gaps	Only test flag=on; removing flag breaks old path	Test both paths (on and off) in unit/integration tests
No audit trail	Cannot see who changed flag or when	Use Azure App Configuration audit logs; log evaluations
Performance	Checking flags on every request adds latency	Cache flag state per request (IFeatureManager does this); use refresh interval

Flag sprawl example

After 2 years, your codebase has 200 feature flags. Most are release toggles that were never retired. The code is full of if (await _featureManager.IsEnabledAsync(...)) checks, many for features that are 100% enabled and stable.

Fix: Run a flag audit. For each flag, ask: “Is this still needed?” If the feature is at 100% for 1+ month, retire the flag (remove from code, delete from config). Set a policy: release toggles must be retired within 3 months.

Stale cache example

You change NewCheckout from true to false in Azure App Configuration, but users still see the new checkout for 5 minutes.

Fix: The app caches flags for CacheExpirationInterval (default 30s). Reduce the interval for faster feedback, or use a webhook (Azure App Configuration can push changes to your app via Event Grid).

You can also explore more patterns in the .NET Architecture resource page.

Summary

Feature flags let you deploy without releasing: ship code behind a flag and enable it only when ready—use Microsoft.FeatureManagement and Azure App Configuration for gradual rollouts, A/B testing, and kill switches. Too many long-lived flags cause sprawl and confusion; retiring release flags when features are stable and caching with short expiry (or push) keeps behaviour predictable and kill switches effective. Next, add one flag for your next risky change, use filters for gradual rollout, and plan retirement when the feature is stable.

Key points:

Use filters (percentage, user, time window) for fine-grained control.
Store flags in Azure App Configuration with dynamic refresh so changes apply without restarting.
Retire release toggles when features are stable (within 3 months) to avoid flag sprawl.
Test both code paths (flag on and off) and log flag evaluations for audit.
Evaluate flags server-side only for security and consistency.

Use the FAQs below as a quick reference.

Position & Rationale

I use feature flags for deploy-without-release (ship code behind a flag, enable when ready), kill switches (turn off a feature instantly without redeploy), and gradual rollouts (percentage, user segment). I prefer server-side evaluation so behaviour is consistent and secure; I avoid client-only flags for anything that affects security or billing. I use Azure App Configuration (or similar) with dynamic refresh so changes apply without restart; I set a short cache expiry for flags that might need to be turned off quickly. I retire release flags within a few months once the feature is stable; I avoid keeping “if (NewCheckout)” forever. I don’t use flags for long-term configuration that isn’t “on/off” or rollout—that belongs in config, not feature management.

Trade-Offs & Failure Modes

Feature flags add branching in code and a dependency on the flag store; you gain control over rollout and instant kill. Caching flag state improves performance but delays propagation of changes; too long and kill switches are slow. Flag sprawl (many flags, never retired) makes code hard to read and test. Failure modes: flags that are never retired; evaluating flags client-side for security-sensitive behaviour; stale cache so “turn off” doesn’t take effect; testing only the “on” path and breaking the “off” path.

What Most Guides Miss

Most guides show how to add a flag but don’t stress retirement—flags that outlive their purpose become technical debt and increase the number of code paths to test. Another gap: cache expiry for flags: if you need a fast kill switch, cache must be short or you need push (e.g. webhook) from the config store. Testing both paths (flag on and off) is often mentioned but underdone—teams ship with the flag on and forget the off path breaks after a refactor. Server-side only for anything that affects security or consistency is underplayed; client-side flags can be tampered with.

Decision Framework

If you need to deploy without releasing → Use a release flag; enable when ready; retire when stable.
If you need to turn off a feature in production quickly → Use a kill-switch flag; keep cache short or use push refresh.
If you need gradual or targeted rollout → Use percentage or targeting filters; store flags in App Configuration (or similar) with refresh.
For every new flag → Plan retirement (e.g. within 3 months); add to backlog to remove when feature is default.
For security or billing → Evaluate flags server-side only; never trust client-side flag state.

Key Takeaways

Use flags for deploy without release, kill switches, and gradual rollouts; evaluate server-side for consistency and security.
Retire release flags when the feature is stable; avoid flag sprawl.
Cache flag state for performance but keep expiry short (or use push) if you need fast kill.
Test both flag-on and flag-off paths; log flag evaluations for audit.
Store flags in Azure App Configuration (or similar) with dynamic refresh.

Need architectural guidance for real-world .NET platforms? I offer consulting for .NET architecture, API platforms, and enterprise system design.

When I Would Use This Again — and When I Wouldn’t

I’d use feature flags again for any production system where we deploy frequently and need gradual rollout or the ability to kill a feature without redeploy. I’d use Azure App Configuration (or equivalent) when we want centralised flag storage and dynamic refresh. I wouldn’t add flags for “maybe we’ll need it”—only when there’s a clear use (release, rollout, kill switch). I also wouldn’t leave release flags in place indefinitely; I’d retire them once the feature is the default and remove the dead code path.

Frequently Asked Questions

What is a feature flag?

A feature flag (also called a feature toggle or feature switch) is a runtime switch that enables or disables a code path without redeploying. Used for gradual rollouts, A/B testing, and kill switches.

What is a feature filter?

A feature filter decides when a flag is on (e.g. percentage of users, specific user list, time window). Combine filters (e.g. 10% AND after date X) for fine control. Built-in filters: PercentageFilter, TimeWindowFilter, TargetingFilter.

How do I add feature flags to ASP.NET Core?

Install Microsoft.FeatureManagement.AspNetCore, then call builder.Services.AddFeatureManagement() in Program.cs. Check flags with await _featureManager.IsEnabledAsync("FeatureName") in controllers or services. Add filters (e.g. .AddFeatureFilter<PercentageFilter>()) for conditional enablement.

What is Azure App Configuration for feature flags?

Azure App Configuration is a managed service that stores feature flags (and key-value config) in Azure. Your app fetches on startup or subscribes to refresh; use labels for per-environment values (dev, staging, prod). Supports Managed Identity for secure access without connection strings in code.

How do I do a gradual rollout with feature flags?

Use a percentage filter (e.g. "Value": 10 for 10% of requests). Increase the percentage over time (25%, 50%, 100%). If issues appear, reduce to 0% as a kill switch without redeploying. Monitor metrics (errors, latency) at each stage.

How do I retire a feature flag?

When the feature is fully rolled out and stable (100% for 1+ week), remove the flag check from code (always use the new path), delete the old code path, then delete the flag from appsettings.json or Azure App Configuration. Test both paths before removing.

Should I evaluate feature flags on the client or server?

Evaluate server-side only for security and consistency. Client-side flags can be tampered with and expose rollout logic. For SPAs or mobile apps, call an API that returns “is feature X enabled for this user?” rather than sending flag state to the client.

What is a kill switch?

A kill switch is the ability to turn off a feature instantly without redeploying. With feature flags, set the flag to false (or percentage to 0) in Azure App Configuration so that all users revert to the old code path. Use when the new feature causes incidents or needs to be disabled quickly.

How do I do A/B testing with feature flags?

Use a percentage filter (e.g. 50%) to assign users to A (old) or B (new). Track metrics (conversion, latency) for each variant. Use consistent assignment (hash user ID) so each user sees the same variant every time. After 1-2 weeks, pick the winner and retire the flag.

What is flag sprawl and how do I avoid it?

Flag sprawl is when too many feature flags are never retired, leaving the codebase full of dead branches. Avoid by retiring release toggles within 3 months of full rollout. Add a “created date” to each flag and review monthly. Only ops and permission toggles should be long-lived.

How do I test code with feature flags?

Write unit and integration tests for both code paths (flag on and flag off). Mock IFeatureManager.IsEnabledAsync() to return true or false. This ensures that removing the flag later does not break the old path.

Can I combine multiple filters for one flag?

Yes. Use "RequirementType": "All" to require all filters to pass (AND), or "RequirementType": "Any" for at least one (OR). Example: enable for 10% of users AND only after a specific date.

How do I use Managed Identity with Azure App Configuration?

In Program.cs, use options.Connect(new Uri(endpoint), new DefaultAzureCredential()) instead of a connection string. Grant the app’s Managed Identity the App Configuration Data Reader role in Azure. This avoids storing secrets in code or config.

What is the difference between release toggles and ops toggles?

Release toggles are short-lived (days to weeks) and hide incomplete features until ready. Ops toggles are long-lived and control operational behaviour (e.g. EnableDetailedLogging, EnableCaching). Release toggles should be retired; ops toggles stay in code.

How do I refresh flags without restarting the app?

Use app.UseAzureAppConfiguration() middleware and set CacheExpirationInterval (e.g. 30 seconds). The app polls Azure App Configuration and picks up changes automatically. For instant updates, use a webhook (Azure App Configuration + Event Grid).

What happens if Azure App Configuration is down?

The app uses the last cached flag values. If the app restarts and cannot reach Azure App Configuration, it falls back to appsettings.json (if configured) or defaults. Use optional: true in AddAzureAppConfiguration() so the app starts even if App Configuration is unavailable.

Related Guides & Resources

Part of cluster

Full-Stack & Data — explore related topics:

Full Stack Development Database Design & Optimization

Waqas Ahmad — Software Architect & Technical Consultant

Distributed Systems

Article

Feature Flags and Toggles in .NET

Read the article

Introduction

Topics covered

Decision Context

What is a feature flag?

Why use feature flags?

Feature flag types

Adding feature flags to ASP.NET Core

Step 1: Install the package

Step 2: Register feature management in Program.cs

Step 3: Configure flags in appsettings.json

Step 4: Check flags in code

Step 5: Use FeatureGate attribute (optional)

Feature filters: percentage, user, time window

Built-in filters

PercentageFilter example

TimeWindowFilter example

TargetingFilter example

Custom filters

Azure App Configuration integration

Why use Azure App Configuration?

Setup: connect ASP.NET Core to Azure App Configuration

Using Managed Identity (recommended for production)

Labels for per-environment flags

Dynamic refresh

Gradual rollout and A/B testing

Gradual rollout

A/B testing

Sticky assignment (consistent user experience)

Kill switches and incident response

Example incident response

Feature flag lifecycle and retirement

Lifecycle stages

How to retire a flag

When to retire

Enterprise best practices

Common issues and challenges

Flag sprawl example

Stale cache example

Summary

Position & Rationale

Trade-Offs & Failure Modes

What Most Guides Miss

Decision Framework

Key Takeaways

When I Would Use This Again — and When I Wouldn’t

Frequently Asked Questions

Frequently Asked Questions

What is a feature flag?

What is a feature filter?

How do I add feature flags to ASP.NET Core?

What is Azure App Configuration for feature flags?

How do I do a gradual rollout with feature flags?

How do I retire a feature flag?

Should I evaluate feature flags on the client or server?

What is a kill switch?

How do I do A/B testing with feature flags?

What is flag sprawl and how do I avoid it?

How do I test code with feature flags?

Can I combine multiple filters for one flag?

How do I use Managed Identity with Azure App Configuration?

What is the difference between release toggles and ops toggles?

How do I refresh flags without restarting the app?

What happens if Azure App Configuration is down?

Related Guides & Resources

Related articles

Part of cluster

Related services