DataDog · vjfridge · Jun 4, 2026 · Jun 4, 2026 · Jun 4, 2026 · Jun 4, 2026
@@ -12,4 +12,5 @@ Learn how Datadog Feature Flags work and how to configure flags, environments, t
     {{< nextlink href="/feature_flags/concepts/traffic_splitting" >}}Traffic Splitting and Randomization{{< /nextlink >}}
     {{< nextlink href="/feature_flags/concepts/distribution_channels" >}}Distribution Channels{{< /nextlink >}}
     {{< nextlink href="/feature_flags/concepts/flag_history" >}}Flag History{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/concepts/flag_graphs" >}}Feature Flag Graphs{{< /nextlink >}}
 {{< /whatsnext >}}
@@ -0,0 +1,72 @@
+---
+title: Feature Flag Graphs
+description: Understand the graphs on the feature flags list and details pages and how to use them to monitor your rollout.
+further_reading:
+- link: "/feature_flags/server/"
+  tag: "Documentation"
+  text: "Server-Side Feature Flags"
+- link: "/feature_flags/client/"
+  tag: "Documentation"
+  text: "Client-Side Feature Flags"
+- link: "/dashboards/"
+  tag: "Documentation"
+  text: "Dashboards"
+---
+
+## Overview
+
+Datadog Feature Flags provides graphs at two levels: the flags list page gives a snapshot of all your flags at a glance, and the flag details page shows in-depth graphs for a single flag.
+
+## Flags list page
+
+The flags list page shows a summary row for each flag, including total evaluation count and mini graph that let you assess activity across your flag inventory without opening each flag individually.
+
+{{< img src="feature_flags/flag_graphs/flag_list.png" alt="Feature flags list page showing evaluation counts and sparklines per flag" style="width:100%;" >}}
+
+Each row shows:
+
+- **Evaluation count**: total number of client and server evaluations in the past hour
+- **Mini graph**: individual client and server evaluations in the past hour, grouped by variant
+- **Variants**: the variant colors are the key for the mini graph
+
+## Flag details page
+
+The flag details page includes observability insights to help you quickly identify how a single flag is performing.
+
+### Targeting rule evaluation counts
+
+Shows the total client and server evaluations that fell through to each targeting rule in the given `Real-time metric overview` time range.
+
+{{< img src="feature_flags/flag_graphs/targeting_rule_distribution.png" alt="Targeting rule evaluation count" style="width:100%;" >}}
+
+Use this count to confirm that targeting rules are working as expected and to see how traffic is distributed across targeting rules in a given environment, including % of total traffic in the time range.
+
+### Client + Server evaluations
+
+{{< img src="feature_flags/flag_graphs/evaluations.png" alt="Client + Server evaluations graph split by variant" style="width:100%;" >}}
+
+Client SDK evaluations have two views, each grouped by variant:
+
+- **Unique**: count of unique users or entities that evaluated each variant (deduplicated by targeting key)
+- **Total**: count of all evaluations by variant, including repeated evaluations of the same targeting key
+
+
-
-
+Server SDK evaluations show count of all evaluations by variant. Requires flag evaluation metrics to be enabled. See [Set Up Server-Side Flag Evaluation Metrics][1].
+
+### Errors and latency
+
+{{< img src="feature_flags/flag_graphs/errors_latency.png" alt="Error and latency graphs" style="width:100%;" >}}
+
+Error rate and latency graphs are available for client evaluations. Server evaluation support is coming soon.
+
+## Export to a dashboard
+
+{{< img src="feature_flags/flag_graphs/dashboard_export.png" alt="Export graph to a dashboard" style="width:100%;" >}}
+
+Choose **Export to Dashboard** to add it to a Datadog dashboard. From there, you can slice and dice the data for further insights.
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /feature_flags/guide/server_flag_evaluation_metrics/
@@ -12,6 +12,7 @@ cascade:
 
 {{< whatsnext desc="Feature Flags Guides:" >}}
     {{< nextlink href="/getting_started/feature_flags" >}}Getting started with Feature Flags{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/guide/server_flag_evaluation_metrics" >}}Set Up Server-Side Flag Evaluation Metrics{{< /nextlink >}}
     {{< nextlink href="/feature_flags/guide/migrate_from_launchdarkly" >}}Migrate Your Feature Flags from LaunchDarkly{{< /nextlink >}}
     {{< nextlink href="/feature_flags/guide/migrate_from_statsig" >}}Migrate Your Feature Flags from Statsig{{< /nextlink >}}
 {{< /whatsnext >}}
@@ -0,0 +1,140 @@
+---
+title: Set Up Server-Side Flag Evaluation Metrics
+description: Configure the Datadog Agent and your application to emit and visualize flag evaluation metrics for server-side feature flags.
+further_reading:
+- link: "/feature_flags/server/"
+  tag: "Documentation"
+  text: "Server-Side Feature Flags"
+- link: "/feature_flags/concepts/flag_graphs/"
+  tag: "Documentation"
+  text: "Feature Flag Graphs"
+- link: "/metrics/"
+  tag: "Documentation"
+  text: "Metrics"
+- link: "/dashboards/"
+  tag: "Documentation"
+  text: "Dashboards"
+---
+
+## Overview
+
+Flag evaluation metrics let you measure how often each variant of a feature flag is returned by your server-side application. Use these metrics to track flag adoption over time, verify targeting rules are working as expected, and graph flag evaluation data on dashboards.
+
+<div class="alert alert-warning">The <code>feature_flag.evaluations</code> metric is experimental and may change or be removed in a future release.</div>
+
+## Prerequisites
+
+Before setting up flag evaluation metrics:
+
+- Server-side feature flags are already configured. See [Server-Side Feature Flags][1].
+- Datadog Agent 7.55 or later is running.
 OTLP Ingest in the Agent is a way to send telemetry data directly from applications instrumented with [OpenTelemetry SDKs][1] to Datadog Agent. Since versions 6.32.0 and 7.32.0, the Datadog Agent can ingest OTLP traces and [OTLP metrics][2] through gRPC or HTTP. Since versions 6.48.0 and 7.48.0, the Datadog Agent can ingest OTLP logs through gRPC or HTTP. 
 OTLP Ingest in the Agent is a way to send telemetry data directly from applications instrumented with [OpenTelemetry SDKs][1] to Datadog Agent. Since versions 6.32.0 and 7.32.0, the Datadog Agent can ingest OTLP traces and [OTLP metrics][2] through gRPC or HTTP. Since versions 6.48.0 and 7.48.0, the Datadog Agent can ingest OTLP logs through gRPC or HTTP. 
+- `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true` is set on your application.
+- Your server-side tracer meets the minimum version for flag evaluation metrics support:
+
+| Language | Minimum tracer version |
+| -------- | ---------------------- |
+| .NET     | 3.44.0                 |
+| Go       | 2.8.0                  |
+| Java     | 1.62.0                 |
+| Node.js  | 5.99.0                 |
+| Python   | 4.7.0                  |
+| Ruby     | 2.32.0                 |
+
+## Step 1: Enable the Agent OTLP receiver
+
+Flag evaluation metrics are emitted over OpenTelemetry (OTLP). The Datadog Agent includes an OTLP receiver, but it is off by default. Enable it with the following environment variables on your Agent:
+
+{{< code-block lang="bash" >}}
+# gRPC endpoint (port 4317)
+DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT=0.0.0.0:4317
+
+# HTTP endpoint (port 4318)
+DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318
+{{< /code-block >}}
 2. For the Datadog Agent container, set the following endpoint environment variables and expose the corresponding port: 
    - For gRPC: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT` to `0.0.0.0:4317` and expose port `4317`. 
 2. For the Datadog Agent container, set the following endpoint environment variables and expose the corresponding port: 
    - For gRPC: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT` to `0.0.0.0:4317` and expose port `4317`. 
+
+You only need to enable the protocol your application uses. Both gRPC and HTTP are shown for reference.
+
+<div class="alert alert-info">If you are running Agent v7.61.0 or later in Docker, set <code>HOST_PROC=/proc</code> on the Agent container to work around a known issue with the OTLP pipeline.</div>
 1. Set the environment variable <code>HOST_PROC</code> to <code>/proc</code> in your Agent Docker container.<br> 
 1. Set the environment variable <code>HOST_PROC</code> to <code>/proc</code> in your Agent Docker container.<br> 
+
+## Step 2: Configure your application
+
+Set the following environment variables on your application in addition to the standard [server-side feature flag configuration][1]:
+
+{{< code-block lang="bash" >}}
+# Enable flag evaluation metrics
+DD_METRICS_OTEL_ENABLED=true
+
+# Point OTLP metrics at the Datadog Agent
+# HTTP endpoint (note the /v1/metrics path suffix):
+OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4318/v1/metrics
+
+# Or use gRPC (no path suffix):
+# OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4317
 Set the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable in your application's environment: 
 For gRPC: 
 ```shell 
 export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" 
 ``` 
 For HTTP: 
 ```shell 
 export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318" 
 ``` 
 Set the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable in your application's environment: 
  
 For gRPC: 
 ```shell 
 export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" 
 ``` 
  
 For HTTP: 
 ```shell 
 export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318" 
 ``` 
+{{< /code-block >}}
+
+Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a Docker Compose setup, this is typically the Agent container's service name.
-## Step 2: Configure your application
-
-Set the following environment variables on your application in addition to the standard [server-side feature flag configuration][1]:
-
-{{< code-block lang="bash" >}}
-# Enable flag evaluation metrics
-DD_METRICS_OTEL_ENABLED=true
-
-# Point OTLP metrics at the Datadog Agent
-# HTTP endpoint (note the /v1/metrics path suffix):
-OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4318/v1/metrics
-
-# Or use gRPC (no path suffix):
-# OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4317
-{{< /code-block >}}
-
-Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a Docker Compose setup, this is typically the Agent container's service name.
+## Step 2: Configure your application
+
+Set the following environment variable on your application, in addition to the
+standard [server-side feature flag configuration][1]:
+
+{{< code-block lang="bash" >}}
+# Enable flag evaluation metrics
+DD_METRICS_OTEL_ENABLED=true
+{{< /code-block >}}
+
+By default, most tracers send OTLP metrics to the Agent at `DD_AGENT_HOST` on port
+`4318`. If your application already sets `DD_AGENT_HOST` to reach the Agent, no
+endpoint configuration is required.
+
+Set an OTLP endpoint explicitly in either of these cases:
+
+- The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example,
+  a remote Agent or a non-default port).
+- You use the **Java** tracer. The Java tracer does not derive the endpoint from
+  `DD_AGENT_HOST`; it defaults to `localhost:4318`. Set the endpoint whenever the
+  Agent is not on `localhost`.
+
+To set the endpoint, use the standard OpenTelemetry variable:
+
+{{< code-block lang="bash" >}}
+# Point OTLP data at the Datadog Agent (HTTP, port 4318)
+OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4318
+
+# Or use gRPC (port 4317). The default protocol is http/protobuf, so you must also
+# set the protocol to grpc when using the gRPC port:
+# OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4317
+# OTEL_EXPORTER_OTLP_PROTOCOL=grpc
+{{< /code-block >}}
+
+Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a
+Docker Compose setup, this is typically the Agent container's service name. To set the
+metrics endpoint independently of other OTLP signals, use
+`OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` instead, and append the `/v1/metrics` path for HTTP.
+
-## Step 2: Configure your application
-
-Set the following environment variables on your application in addition to the standard [server-side feature flag configuration][1]:
-
-{{< code-block lang="bash" >}}
-# Enable flag evaluation metrics
-DD_METRICS_OTEL_ENABLED=true
-
-# Point OTLP metrics at the Datadog Agent
-# HTTP endpoint (note the /v1/metrics path suffix):
-OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4318/v1/metrics
-
-# Or use gRPC (no path suffix):
-# OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://<AGENT_HOST>:4317
-{{< /code-block >}}
-
-Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a Docker Compose setup, this is typically the Agent container's service name.
+## Step 2: Configure your application
+
+Set the following environment variable on your application, in addition to the
+standard [server-side feature flag configuration][1]:
+
+{{< code-block lang="bash" >}}
+# Enable flag evaluation metrics
+DD_METRICS_OTEL_ENABLED=true
+{{< /code-block >}}
+
+By default, most tracers send OTLP metrics to the Agent at `DD_AGENT_HOST` on port
+`4318`. If your application already sets `DD_AGENT_HOST` to reach the Agent, no
+endpoint configuration is required.
+
+Set an OTLP endpoint explicitly in either of these cases:
+
+- The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example,
+  a remote Agent or a non-default port).
+- You use the **Java** tracer. The Java tracer does not derive the endpoint from
+  `DD_AGENT_HOST`; it defaults to `localhost:4318`. Set the endpoint whenever the
+  Agent is not on `localhost`.
+
+To set the endpoint, use the standard OpenTelemetry variable:
+
+{{< code-block lang="bash" >}}
+# Point OTLP data at the Datadog Agent (HTTP, port 4318)
+OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4318
+
+# Or use gRPC (port 4317). The default protocol is http/protobuf, so you must also
+# set the protocol to grpc when using the gRPC port:
+# OTEL_EXPORTER_OTLP_ENDPOINT=http://<AGENT_HOST>:4317
+# OTEL_EXPORTER_OTLP_PROTOCOL=grpc
+{{< /code-block >}}
+
+Replace `<AGENT_HOST>` with the hostname or IP address of your Datadog Agent. In a
+Docker Compose setup, this is typically the Agent container's service name. To set the
+metrics endpoint independently of other OTLP signals, use
+`OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` instead, and append the `/v1/metrics` path for HTTP.
+
+
+## Docker Compose example
+
+{{< code-block lang="yaml" filename="docker-compose.yml" >}}
+services:
+  datadog-agent:
+    environment:
+      - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT=0.0.0.0:4317
+      - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318
+      - HOST_PROC=/proc  # Required for Agent v7.61.0+ running in Docker
 2. For the Datadog Agent container, set the following endpoint environment variables and expose the corresponding port: 
    - For gRPC: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT` to `0.0.0.0:4317` and expose port `4317`. 
    - For HTTP: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT` to `0.0.0.0:4318` and expose port `4318`. 
 2. For the Datadog Agent container, set the following endpoint environment variables and expose the corresponding port: 
    - For gRPC: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT` to `0.0.0.0:4317` and expose port `4317`. 
    - For HTTP: Set `DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT` to `0.0.0.0:4318` and expose port `4318`. 
+
+  app-go:
+    environment:
+      - DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
+      - DD_METRICS_OTEL_ENABLED=true
+      - OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://datadog-agent:4318/v1/metrics
+    depends_on:
+      datadog-agent:
+        condition: service_healthy
+{{< /code-block >}}
+
+## Step 3: Verify metrics are flowing
+
+After deploying, confirm metrics are reaching Datadog:
+
+1. Go to [Metrics Explorer][2] and search for `feature_flag.evaluations`.
+2. If the metric does not appear within a few minutes of your application evaluating flags, check:
+   - The Agent OTLP receiver is enabled and the correct port is exposed.
+   - `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` points to the Agent, not a separate collector.
+   - Your application is actively evaluating flags via a server sdk at runtime (the code path is being executed).
+
+## Step 4: Enable metric retention
+
+By default, `feature_flag.evaluations` retains only one hour of data. To retain a longer history:
+
+1. Go to [Metrics Summary][3] and search for `feature_flag.evaluations`.
+2. Select the metric and enable **Historical Metrics**.
+
+This is an opt-in setting and is not enabled automatically for OTLP metrics.
+
+## Graph flag evaluations on a dashboard
+
+Use the following query to graph flag evaluations by flag key and variant on a [dashboard][4]:
+
+{{< code-block lang="text" >}}
+sum:feature_flag.evaluations{*} by {feature_flag.key,feature_flag.result.variant}
+{{< /code-block >}}
+
+The `feature_flag.evaluations` metric is a counter with the following tags:
+
+| Tag                                  | Description                            |
+| ------------------------------------ | -------------------------------------- |
+| `feature_flag.key`                   | The flag key being evaluated           |
+| `feature_flag.result.variant`        | The variant returned by the evaluation |
+| `feature_flag.result.reason`         | The reason for the evaluation result   |
+| `feature_flag.result.allocation_key` | The targeting rule id                  |
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /feature_flags/server/
+[2]: https://app.datadoghq.com/metric/explorer
+[3]: https://app.datadoghq.com/metric/summary
+[4]: /dashboards/
@@ -8,6 +8,12 @@ further_reading:
 - link: "/remote_configuration/"
   tag: "Documentation"
   text: "Remote Configuration"
+- link: "/feature_flags/guide/server_flag_evaluation_metrics/"
+  tag: "Guide"
+  text: "Set Up Server-Side Flag Evaluation Metrics"
+- link: "/feature_flags/concepts/flag_graphs/"
+  tag: "Concept"
+  text: "Feature Flag Graphs"
 ---
 
 ## Overview
@@ -69,14 +75,14 @@ DD_TRACE_AGENT_PORT=8126
 DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
 
 # Optional: Enable flag evaluation metrics
-DD_METRICS_OTEL_ENABLED=true
+# See "Set Up Server-Side Flag Evaluation Metrics" documentation
 {{< /code-block >}}
 
 <div class="alert alert-warning">The <code>DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true</code> environment variable is required to enable the feature flagging provider. Java also supports the system property <code>-Ddd.experimental.flagging.provider.enabled=true</code>, and Ruby and Node.js support code-based configuration as an alternative. See the SDK-specific documentation for details.</div>
 
 <div class="alert alert-info">Remote Configuration must be available for server-side Feature Flags. It is enabled by default on Agent 7.47.0 and later. Only set SDK-level Remote Configuration variables (such as <code>DD_REMOTE_CONFIG_ENABLED=true</code>) if your tracer has Remote Configuration disabled and you need to override that setting.</div>
 
-<div class="alert alert-info">Set <code>DD_METRICS_OTEL_ENABLED=true</code> to enable flag evaluation metrics. Without this, the SDK does not emit metrics for flag evaluations. When enabled, each evaluation records a <code>feature_flag.evaluations</code> counter metric tagged with the flag key, result variant, and evaluation reason.</div>
+See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a> to enable the experimental <code>feature_flag.evaluations</code> metric. See <a href="/feature_flags/concepts/flag_graphs/">Feature Flag Graphs</a> for more information on available graphing.
 
 ## Testing with in-memory providers
 

@@ -8,6 +8,12 @@ further_reading:
 - link: "/tracing/trace_collection/dd_libraries/dotnet-core/"
   tag: "Documentation"
   text: ".NET Tracing"
+- link: "/feature_flags/guide/server_flag_evaluation_metrics/"
+  tag: "Guide"
+  text: "Set Up Server-Side Flag Evaluation Metrics"
+- link: "/feature_flags/concepts/flag_graphs/"
+  tag: "Concept"
+  text: "Feature Flag Graphs"
 ---
 
 ## Overview
@@ -33,7 +39,7 @@ Set the following environment variables:
 DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
 
 # Optional: Enable flag evaluation metrics
-DD_METRICS_OTEL_ENABLED=true
+# See "Set Up Server-Side Flag Evaluation Metrics" documentation
 
 # Required: Service identification
 DD_SERVICE=<YOUR_SERVICE_NAME>
@@ -42,6 +48,8 @@ DD_ENV=<YOUR_ENVIRONMENT>
 
 <div class="alert alert-info">The <code>EXPERIMENTAL_</code> prefix is retained for backwards compatibility; the provider itself is stable.</div>
 
+See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a> to enable the experimental <code>feature_flag.evaluations</code> metric. See <a href="/feature_flags/concepts/flag_graphs/">Feature Flag Graphs</a> for more information on available graphing.
+
 ## Installation
 
 Install the Datadog [.NET SDK][3] and [OpenFeature SDK][4] using NuGet:

@@ -8,6 +8,12 @@ further_reading:
 - link: "/tracing/trace_collection/dd_libraries/go/"
   tag: "Documentation"
   text: "Go Tracing"
+- link: "/feature_flags/guide/server_flag_evaluation_metrics/"
+  tag: "Guide"
+  text: "Set Up Server-Side Flag Evaluation Metrics"
+- link: "/feature_flags/concepts/flag_graphs/"
+  tag: "Concept"
+  text: "Feature Flag Graphs"
 ---
 
 ## Overview
@@ -31,7 +37,7 @@ Set the following environment variables:
 DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
 
 # Optional: Enable flag evaluation metrics
-DD_METRICS_OTEL_ENABLED=true
+# See "Set Up Server-Side Flag Evaluation Metrics" documentation
 
 # Required: Service identification
 DD_SERVICE=<YOUR_SERVICE_NAME>
@@ -40,6 +46,8 @@ DD_ENV=<YOUR_ENVIRONMENT>
 
 <div class="alert alert-info">The <code>EXPERIMENTAL_</code> prefix is retained for backwards compatibility; the provider itself is stable.</div>
 
+See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a> to enable the experimental <code>feature_flag.evaluations</code> metric. See <a href="/feature_flags/concepts/flag_graphs/">Feature Flag Graphs</a> for more information on available graphing.
+
 ## Installation
 
 Install the Datadog OpenFeature provider package:

@@ -8,10 +8,18 @@ further_reading:
 - link: "/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/"
   tag: "Documentation"
   text: "Java APM and Distributed Tracing"
+- link: "/feature_flags/guide/server_flag_evaluation_metrics/"
+  tag: "Guide"
+  text: "Set Up Server-Side Flag Evaluation Metrics"
+- link: "/feature_flags/concepts/flag_graphs/"
+  tag: "Concept"
+  text: "Feature Flag Graphs"
 ---
 
 <div class="alert alert-info">Enable Java Feature Flags by setting <code>DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true</code>. The <code>EXPERIMENTAL_</code> prefix is kept for backwards compatibility; the provider is stable. See the <a href="#configuration">Configuration section</a> for details.</div>
 
+See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a> to enable the experimental <code>feature_flag.evaluations</code> metric. See <a href="/feature_flags/concepts/flag_graphs/">Feature Flag Graphs</a> for more information on available graphing.
+
 ## Overview
 
 This page describes how to instrument a Java application with the Datadog Feature Flags SDK. Datadog feature flags provide a unified way to remotely control feature availability in your app, experiment safely, and deliver new experiences with confidence.
@@ -122,7 +130,7 @@ Configure your Java application with the required environment variables or syste
 export DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
 
 # Optional: Enable flag evaluation metrics
-export DD_METRICS_OTEL_ENABLED=true
+# See "Set Up Server-Side Flag Evaluation Metrics" documentation
 
 # Required: Service name
 export DD_SERVICE=<YOUR_SERVICE_NAME>
@@ -142,7 +150,6 @@ java -javaagent:path/to/dd-java-agent.jar -jar your-application.jar
 {{< code-block lang="bash" >}}
 java -javaagent:path/to/dd-java-agent.jar \
   -Ddd.experimental.flagging.provider.enabled=true \
-  -Ddd.metrics.otel.enabled=true \
   -Ddd.service=<YOUR_SERVICE_NAME> \
   -Ddd.env=<YOUR_ENVIRONMENT> \
   -Ddd.version=<YOUR_APP_VERSION> \
@@ -161,9 +168,8 @@ The Datadog feature flagging system starts automatically when the tracer is init
 
 For instructions on how to add the `-javaagent` argument to your application server or framework, see [Add the Java SDK to the JVM](/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/#add-the-java-sdk-to-the-jvm).
 
-Make sure to include the feature flagging configuration flags:
+Make sure to include the feature flagging configuration flag:
 - `-Ddd.experimental.flagging.provider.enabled=true`
-- `-Ddd.metrics.otel.enabled=true` if you want flag evaluation metrics
 
 ## Initialize the OpenFeature provider
 
@@ -660,7 +666,7 @@ Review `reason` and `errorCode` to understand why the provider returned a given
 
 #### Flag evaluation metrics
 
-Flag evaluation counts appear in Datadog when `DD_METRICS_OTEL_ENABLED=true` is set on the tracer. Each evaluation emits a `feature_flag.evaluations` counter metric tagged with the flag key, result variant, and evaluation reason. If this metric does not appear, verify the setting is enabled and the tracer version supports it.
+Flag evaluation counts appear in Datadog as a `feature_flag.evaluations` counter metric tagged with the flag key, result variant, and evaluation reason. See <a href="/feature_flags/guide/server_flag_evaluation_metrics/">Set Up Server-Side Flag Evaluation Metrics</a> for the full setup guide and troubleshooting steps.
 
 #### Experiment exposures