Engineering Leaders: FinOps Fix for Feature Flag Costs with MFCR

Feature flags do not automatically raise your cloud bill, and they do not automatically lower it either. They reduce remediation and business risk by letting you roll back a bad release in seconds rather than hours, but they also introduce recurring vendor charges and cloud overhead that grow quietly if nobody watches them. The financial outcome depends on how you configure polling, which SDKs you deploy, and whether you govern flag lifecycle. Get those levers right, and flags pay for themselves. Ignore them and the bill creeps.

---

TL;DR:

• Most feature flag vendors charge based on request activity, primarily for configuration fetches, not on the number of flags deployed.
• Remote evaluation and frequent polling can significantly increase infrastructure costs and latency, especially in high-throughput systems.
• Effective cost control includes lengthening polling intervals, consolidating configuration delivery, and removing obsolete flags to prevent hidden spending growth.
• Self-hosting is advantageous for mature teams with existing platform capacity, while SaaS options suit smaller teams or unpredictable traffic.
• A proactive FinOps approach involves regular review, environment-specific analysis, and setting alerts to verify savings and prevent runaway cloud bills.

---

How feature flag vendors actually bill you

Most vendors do not charge per flag. They charge for activity, and the dominant meter is the configuration request, not the evaluation. Datadog's documentation on Monthly Flag Configuration Requests explains that each time an SDK asks for the configuration file, that counts as one MFCR. Evaluations happen locally on the client or server and are not billed separately, which means the request pattern matters far more than the number of flags you run.

Other vendors bill on API requests, monthly active users, or SDK connection counts. Flag count alone predicts almost nothing about your invoice.

A rough MFCR estimate looks like this:

• Count your running hosts or containers using server-side SDKs.
• Multiply by requests per polling cycle (once per interval, typically every 30 seconds by default).
• Add client-side session volume, since each user session can trigger its own configuration fetch.

Ten server-side pods polling every 30 seconds already generate tens of thousands of requests a month before a single user session is added.

Where feature flags push up your cloud spend

Vendor bills are only half the story. The other half lives in your own infrastructure, and it is easy to miss because it never appears as a line item labelled "feature flags."

Remote evaluation and frequent polling add network calls and CPU cycles on every request. In high-throughput systems this can force you to run extra server pods just to absorb the overhead, which turns a flagging decision into a genuine infrastructure cost. Datadog's guidance on estimating and managing feature flag costs notes that practitioner measurements put per-flag remote evaluation latency in the low tens of milliseconds in some high-throughput environments. That sounds trivial until you multiply it across millions of requests a day.

In high-throughput environments, remote flag evaluation can add low tens of milliseconds of latency per request, according to Datadog's cost guidance. At scale, that latency either slows response times or forces you to provision more compute to hold your service-level targets.

Local caching reduces network calls and cuts latency, but it introduces its own risk: a stale cache can mean a flag change does not take effect when you expect it to, which sends engineers scrambling to diagnose a rollout that appears not to have worked.

Self-hosted versus SaaS: comparing the real cost of ownership

Licence price is the number everyone compares, and it is the least useful one. A proper total cost of ownership comparison covers four buckets: licence or usage fees, infrastructure, operations (the engineer hours spent running and maintaining the system), and governance tooling. The FeatBit TCO model argues that ops time and governance overhead are the categories teams consistently underestimate when they compare self-hosting against a SaaS vendor.

• Self-hosting tends to make sense when you already run the platform engineering capacity to operate another service and want to avoid per-request billing entirely.
• SaaS tends to make sense when your team is small, your traffic is unpredictable, or you would rather pay for predictable usage than staff an internal on-call rotation for flag infrastructure.
• FeatBit's own examples show the break-even point shifting around team sizes near 50 engineers, where the operational cost of self-hosting starts to be absorbed by existing headcount rather than added specifically for flags.

Say a team of 15 engineers is choosing between the two: with no spare platform capacity, the ops bucket alone usually tips the decision towards SaaS, even before licence cost is compared.

Concrete levers to reduce your feature flag bill

Most of the cost in a flagging system is discretionary, which means most of it is fixable without touching your product roadmap.

1. Lengthen polling intervals in non-critical environments, since staging and QA rarely need a 30-second refresh cycle.
2. Consolidate configuration delivery so CI runners and short-lived branch environments are not each polling independently.
3. Restrict client-side SDK initialisation to the applications that genuinely need real-time flag state, and use bootstrapping to avoid an initial fetch on every page load.
4. Archive flags once their rollout is complete rather than leaving them live and polling indefinitely.
5. Set billing alerts and usage quotas on your flagging vendor account so a runaway polling loop gets caught before the invoice does.

PostHog's guidance on cutting feature flag costs makes the same point from the vendor side: default local-evaluation fetch intervals can produce large request volumes, and disabling automatic fetches or lengthening the interval is often the single biggest lever available.

Pro Tip: Move non-production environments from a 30-second poll to a 5-minute poll first. It is usually the highest-impact change available, and it costs nothing to test.

Governance and flag lifecycle: preventing quiet cost growth

Cost control eventually becomes a governance problem, because the flags nobody remembers to remove are the ones still polling every 30 seconds a year later.

• Assign an owner to every flag and set an expiry date at creation, so short-lived flags do not become permanent by accident.
• Enforce clear naming conventions, role-based access control, and audit logs, so unauthorised toggles are rare and root cause analysis is fast when something does go wrong.
• Build scheduled flag reviews into your release process and integrate stale-flag detection into CI/CD, so a flag is removed once its rollout has finished rather than lingering as technical debt.

How a FinOps approach turns flag usage into verified savings

Cost control on feature flags follows the same discipline as any other FinOps problem: find the waste, fix the highest-impact item first, and confirm the saving on the actual bill.

• Break down MFCR or request volume by environment, service, and feature to find which polling loops are driving spend.
• Typical fixes: lengthen polling on non-critical environments, consolidate configuration delivery across CI runners, and decommission SDKs left running in unused environments.
• A model that runs assessment, execution, and verification as one loop counts a proposed fix as a saving only once it shows up on the bill, and success-fee engagements are priced based on realised savings.

A decision checklist for engineering leaders

Before budgeting for feature flags, check five things: your deployment cadence, expected client-side session volume, the number of hosts or containers running server-side SDKs, how mature your flag governance already is, and whether you have monitoring in place to catch a cost spike early. Your budget line items should include vendor licence or usage cost, the infrastructure delta from added polling load, ops hours for governance, and any tooling cost. Treat flags as an ongoing FinOps cost centre with a regular review cadence, not a one-off procurement decision.

Where feature flags earn their keep and where they do not

Feature flags deliver the strongest return where a bad rollout is expensive to fix quickly, controlled exposure genuinely reduces business risk, and the team can act on a rollback signal fast. Forrester's TEI analysis of a composite organisation found faster remediation and improved developer efficiency were the main sources of value, weighed against defined implementation and licence costs, according to the Forrester TEI report.

For some very high-throughput systems, a canary deployment or a platform-level change may suit the architecture better than a remote flag check on every request, and the two approaches are not mutually exclusive. What flags cannot do is replace engineering discipline. DORA's research on DevOps transformation found that elite teams pair release controls with trunk-based development and automated testing rather than relying on flags alone. Buy the tool, but keep the practice.

Turning flag and cloud cost analysis into a measured saving

If reading this made you wonder how much your own polling intervals and SDK footprint are costing you, that is exactly the gap Koritsu closes. Rather than a dashboard telling you spend went up, our platform traces the increase back to the service, environment, or SDK causing it, and our engineers help you fix it. We start with a free Savings Opportunity Report that surfaces where flag-related polling, unused environments, or oversized compute are adding cost.

From there, teams that want ongoing coverage move to FinOps as a Service, with Monitor, Advisor, Embedded, and Premium tiers depending on how hands-on you want us to be. Our initial engagements run on a success fee, so you pay only once a saving is verified against your actual bill. Get your free assessment to see what your own flag and cloud footprint is quietly costing you.

Sources

• Monthly Flag Configuration Requests (MFCR) | Datadog documentation
• The Total Economic Impact™ Of LaunchDarkly | Forrester
• Cutting costs for feature flags | PostHog docs

FAQ

What are the downsides of using feature flags?

Feature flags add recurring vendor usage charges and, if polling intervals are left at default settings, extra network and compute overhead on your own infrastructure. Left ungoverned, they also accumulate as stale "flag debt" that adds maintenance cost and confuses root cause analysis when something breaks.

What is the point of a feature flag?

A feature flag lets you turn a piece of functionality on or off without a new deployment, which makes rollbacks fast and reduces the cost of a bad release. That speed is the main financial benefit identified in Forrester's TEI analysis of flagging platforms.

Should you remove feature flags?

Yes, a flag should be removed once its rollout or experiment is complete, since a flag left live keeps polling and adds to both your vendor bill and your codebase's technical debt. Setting an expiry date or owner at creation is the most reliable way to make sure that happens.

What are the best practices for feature flagging?

Assign an owner and an expiry to every flag, use role-based access control and audit logs, and lengthen polling intervals in non-critical environments to cut unnecessary requests. Pairing flags with trunk-based development and automated testing, as DORA's research recommends, is what makes the practice sustainable rather than a source of growing cost.