Add guide for estimating and managing Feature Flags costs

[A-Rindone]

What does this PR do? What is the motivation?

Adds a new Feature Flags guide covering how to estimate usage and costs before rollout, and concrete levers to manage and reduce costs after going live. Links the guide from the Feature Flags guides index.

Merge readiness

• Ready for merge

For Datadog employees:

AI assistance

Drafted with Claude Code based on existing Feature Flags product documentation and internal technical references; reviewed and lint-checked (Vale) before submission.

Additional notes

This guide links to /feature_flags/concepts/monthly_flag_configuration_requests/, which is being added in a separate, parallel PR.

[github-actions]

Preview links (active after the build_preview check completes)

New or renamed files

• https://docs-staging.datadoghq.com/anthony.rindone/estimating-managing-feature-flags-costs/feature_flags/guide/estimating_and_managing_costs

Modified Files

• https://docs-staging.datadoghq.com/anthony.rindone/estimating-managing-feature-flags-costs/feature_flags/guide/

[buraizu]

Thanks for the PR, I've created DOCS-15284 for documentation team review

[joepeeples]

Thanks for adding this great info to the docs! Flagged a broken link similar to #38667 (comment), will follow up with @A-Rindone on merge strategy to resolve.

Mostly line-edits for other comments, including pluralizing MFCRs in most instances as that seems clearer and more readable.

[joepeeples]

We should avoid stating specific pricing/free usage amounts, as they can change and make the docs stale. We're already linking to the pricing page so we can lean on that as source of truth for pricing. Also, omit temporal words like "current":

Suggested change

	Usage under 1 million MFCR per month is included at no cost. For current pricing tiers above that allotment, see the [Feature Flags pricing page][4].
	Feature Flags includes a monthly MFCR allotment at no cost, with usage above it billed by pricing tier. For details on the included allotment and tiers, see the [Feature Flags pricing page][4].

[joepeeples]

Suggested change

For agentless server-side delivery, `DD_FEATURE_FLAGS_CONFIGURATION_SOURCE_AGENTLESS_POLL_INTERVAL_SECONDS` controls how often the SDK requests configuration, with a default of 30 seconds and a maximum of 3600 seconds (one hour). A longer interval reduces request volume at the cost of slower flag propagation. Extending the interval on lower-priority environments, such as development or staging, is one way to lower volume where fast propagation matters less than in production.

For agentless server-side delivery, `DD_FEATURE_FLAGS_CONFIGURATION_SOURCE_AGENTLESS_POLL_INTERVAL_SECONDS` controls how often the SDK requests configuration, with a default of 30 seconds and a maximum of 3,600 seconds (one hour). A longer interval reduces request volume at the cost of slower flag propagation. Extending the interval on lower-priority environments, such as development or staging, is one way to lower volume where fast propagation matters less than in production.

[joepeeples]

Optional — this section is about disabling the SDK provider/polling, not turning off individual flags; a more precise heading is a stronger retrieval anchor.

Suggested change

	### Turn off feature flags where they aren't in use
	### Disable the flags provider where it isn't used

[joepeeples]

Just to break up a long paragraph:

Suggested change

	Feature Flags usage scales with how you deploy flags. For client-side usage, it depends on the number of client applications and end users connecting to Datadog. For server-side usage, it depends on the number of backend services polling for configuration. Two organizations with the same number of flags can generate different amounts of usage, depending on this deployment footprint. This guide helps you estimate usage and cost before you roll out broadly. It also covers the levers available to manage and reduce cost after you're live.
	Feature Flags usage scales with how you deploy flags. For client-side usage, it depends on the number of client applications and end users connecting to Datadog. For server-side usage, it depends on the number of backend services polling for configuration. Two organizations with the same number of flags can generate different amounts of usage, depending on this deployment footprint.
	This guide helps you estimate usage and cost before you roll out broadly. It also covers the levers available to manage and reduce cost after you're live.

[joepeeples]

As with #38667 (comment), this link will 404 until the target page actually exists. Not a big problem if we're expecting to merge both PRs nearly simultaneously. But if there's a substantial delay between them I'd remove the link in the first PR to merge, then add it in the subsequent PR.

[joepeeples]

Suggested change

	For example, an organization with 1.2 million daily active users on flagged client applications generates approximately 36 million MFCR per month (1.2 million x 30 days).
	For a server-side example, an organization running the SDK on 33 hosts generates 2,880 configuration requests per host per day at the default 30-second polling interval (86,400 seconds per day / 30 seconds). That's 33 x 2,880 x 30 days = 2,851,200 (approximately 2.85 million) MFCR before the server-side multiplier, or approximately 28.5 million MFCR after it.
	For example, an organization with 1.2 million daily active users on flagged client applications generates approximately 36 million MFCRs per month (1.2 million x 30 days).
	For a server-side example, an organization running the SDK on 33 hosts generates 2,880 configuration requests per host per day at the default 30-second polling interval (86,400 seconds per day / 30 seconds). That's 33 x 2,880 x 30 days = 2,851,200 (approximately 2.85 million) MFCRs before the server-side multiplier, or approximately 28.5 million MFCRs after it.

[joepeeples]

Suggested change

	Because MFCR tracks configuration requests rather than flag count, reducing the number of flags you maintain doesn't by itself reduce cost. The following levers target what actually drives MFCR: how many client sessions initialize the SDK, how many server instances poll for configuration, and how often.
	Because MFCRs track configuration requests rather than flag count, reducing the number of flags you maintain doesn't by itself reduce cost. The following levers target what actually drives MFCRs: how many client sessions initialize the SDK, how many server instances poll for configuration, and how often.

[joepeeples]

Suggested change

Server-side MFCR multiplies with every environment running an instance of the SDK. Review which [environments][3] genuinely need live server-side flag delivery. Ephemeral or short-lived infrastructure, such as per-branch or CI environments, adds request volume without adding rollout value if it doesn't need targeting. Consolidate environment queries where multiple `env` values map to the same logical environment, so you're not duplicating configuration delivery unnecessarily.

Server-side MFCRs multiply with every environment running an instance of the SDK. Review which [environments][3] genuinely need live server-side flag delivery. Ephemeral or short-lived infrastructure, such as per-branch or CI environments, adds request volume without adding rollout value if it doesn't need targeting. Consolidate environment queries where multiple `env` values map to the same logical environment, so you're not duplicating configuration delivery unnecessarily.

[joepeeples]

Suggested change

	Client-side MFCR tracks sessions or app opens in applications that initialize the flags provider. Initialize the provider only in the applications and properties where you gate features with flags, rather than universally across every client property.
	Client-side MFCRs track sessions or app opens in applications that initialize the flags provider. Initialize the provider only in the applications and properties where you gate features with flags, rather than universally across every client property.

[joepeeples]

Suggested change

[Stale flags][7] don't directly add to MFCR, since a configuration request covers all your flags regardless of count. Archiving them still reduces flag debt and the risk of maintaining logic tied to services or environments you no longer need. Reviewing stale flags is also a useful signal for decommissioning entire environments or SDK deployments that are no longer in use, which does reduce server-side request volume.

[Stale flags][7] don't directly add to MFCRs, since a configuration request covers all your flags regardless of count. Archiving them still reduces flag debt and the risk of maintaining logic tied to services or environments you no longer need. Reviewing stale flags is also a useful signal for decommissioning entire environments or SDK deployments that are no longer in use, which does reduce server-side request volume.

[jhgilbert]

[Automated message] This PR has merge conflicts caused by the recent docs repo reorg (files moved from the repo root into hugo/). A new PR with your commits translated to the correct paths has been opened: #38889

Please follow the instructions in the PR description.

This is an automated comment, but if you have a question, you can mention me in this PR (external contributors) or reach out in #docs-repo-reorg-support on Slack (internal contributors).