[pull] master from DataDog:master

hugo/config/_default/menus/main.en.yaml

@@ -2709,16 +2709,21 @@ menu:
       parent: incidents_settings
       identifier: incidents_settings_property_fields
       weight: 202
+    - name: Transition Forms
+      url: incident_response/incident_management/setup_and_configuration/transition_forms
+      parent: incidents_settings
+      identifier: incidents_settings_transition_forms
+      weight: 203
     - name: Responder Types
       url: incident_response/incident_management/setup_and_configuration/responder_types
       parent: incidents_settings
       identifier: incidents_settings_responder_types
-      weight: 203
+      weight: 204
     - name: Automations
       url: incident_response/incident_management/setup_and_configuration/automations
       parent: incidents_settings
       identifier: incidents_settings_automations
-      weight: 204
+      weight: 205
     - name: Notification Rules
       url: incident_response/incident_management/setup_and_configuration/notification_rules
       parent: incidents_settings

hugo/config/_default/params.yaml

@@ -288,6 +288,7 @@ core_product:
 
 # Unsupported sites for each product
 unsupported_sites:
+  ownership_of_views: [gov, gov2]
   ai_credit_limits: [gov, gov2]
   amazon-security-lake: [gov, gov2]
   resource_catalog_policies: [gov, gov2]
@@ -383,6 +384,7 @@ unsupported_sites:
   linear_error_tracking: [gov,gov2]
   live_debugger: [gov,gov2]
   llm_observability: [gov,gov2]
+  dd.llm_observability.dataset: [gov,gov2]
   mcp_server: [gov,gov2]
   mobile_app_testing: [gov,gov2]
   nebius-cloud: [gov,gov2]
@@ -429,3 +431,4 @@ unsupported_sites:
   workflow-automation: [gov,gov2]
   workflows: [gov,gov2]
   workload_security_active_protection: [gov,gov2]
+  work_management_ai_site_support: [gov,gov2]

hugo/content/en/cloud_cost_management/recommendations/_index.md

@@ -444,6 +444,12 @@ multifiltersearch:
       recommendation_type: Delete Container Registry
       recommendation_description: A Container Registry that has never received successful pulls.
       recommendation_prerequisites: ""
+    - category: Configure
+      cloud_provider: Azure
+      resource_type: Foundry Account
+      recommendation_type: Optimize Prompt Caching
+      recommendation_description: Identifies Azure Foundry accounts already using prompt caching below the target hit rate and recommends improving cache configuration to reduce input token costs.
+      recommendation_prerequisites: ""
     - category: Terminate
       cloud_provider: Azure
       resource_type: Data Explorer Cluster

hugo/content/en/containers/kubernetes/distributions.md

@@ -38,8 +38,8 @@ These configurations can then be customized to add any Datadog feature.
 * [Red Hat OpenShift](#Openshift)
 * [Rancher](#Rancher)
 * [Oracle Container Engine for Kubernetes (OKE)](#OKE)
-* [vSphere Kubernetes Service (VKS)](#VKS)
-* [vSphere Tanzu Kubernetes Grid (TKG)](#TKG)
+* [VMware vSphere Kubernetes Service (VKS)](#VKS)
+* [VMware vSphere Tanzu Kubernetes Grid (TKG)](#TKG)
 
 ## AWS Elastic Kubernetes Service (EKS) {#EKS}
 
@@ -678,7 +678,7 @@ agents:
 
 No specific configuration is required.
 
-## vSphere Kubernetes Service (VKS) {#VKS}
+## VMware vSphere Kubernetes Service (VKS) {#VKS}
 
 VKS requires the namespace where the Datadog Agent is deployed to use the privileged Pod Security Standard. Before deploying the Datadog Agent, replace `<namespace>` with the namespace where you deploy `datadog-agent` and run:
 
@@ -752,7 +752,7 @@ agents:
 
 {{< /tabs >}}
 
-## vSphere Tanzu Kubernetes Grid (TKG) {#TKG}
+## VMware vSphere Tanzu Kubernetes Grid (TKG) {#TKG}
 
 TKG requires some small configuration changes, shown below. For example, setting a toleration is required for the controller to schedule the Node Agent on the `master` nodes.
 

hugo/content/en/delivery_performance/dora_metrics/data_collected/_index.md

@@ -86,6 +86,22 @@ For more information about using custom tags in DORA Metrics, see [DORA Metrics
 | `Deploy Time`       | Duration from start of deployment to end of deployment. |
 | `Number of Commits`       | Count of commits included in the pull request. |
 | `Number of Reviewers`       | Count of reviewers who reviewed the pull request. |
+| `Number of Files Changed` | Count of files changed in the pull request. Only available for GitHub. |
+| `Number of Lines Added` | Count of lines added in the pull request. Only available for GitHub. |
+| `Number of Lines Deleted` | Count of lines deleted in the pull request. Only available for GitHub. |
+| `Total Number of Lines Changed` | Total count of lines added and deleted in the pull request. Only available for GitHub. |
+| `Time to First Human Review` | Duration until the pull request receives its first review from a human. Only available for GitHub. |
+| `Number of Comments` | Count of comments on the pull request. Only available for GitHub. |
+| `Number of Human Comments` | Count of comments on the pull request from humans. Only available for GitHub. |
+| `Fully Automated` | Boolean indicating whether the pull request was created and merged without human involvement. |
+| `Creator Bot Type` | Type of bot that created the pull request. |
+| `Creator Bot Name` | Name of the bot that created the pull request. |
+| `Time CI Failing` | Total duration that CI remained in a failing state across commits in the pull request. Requires CI Visibility. |
+| `Test Session Duration` | Total duration of test sessions for the pull request's head or merge commit. Requires Test Optimization. |
+| `Test Session Duration After Approval` | Total duration of test sessions for the pull request's head or merge commit after the pull request was approved. Requires Test Optimization. |
+| `Time to Pass` | Duration from the first CI attempt until the first successful pipeline execution for the pull request's head or merge commit. Requires CI Visibility. |
+| `Time to Pass After Approval` | Duration from the first CI attempt after pull request approval until the first successful pipeline execution for the pull request's head or merge commit. Requires CI Visibility. |
+| `Patch Coverage` | Percentage of new or modified lines in the pull request's head or merge commit that are covered by tests. Requires Code Coverage. |
 
 
 ### Commit fields
@@ -98,6 +114,9 @@ For more information about using custom tags in DORA Metrics, see [DORA Metrics
 | `Merge Time`       | Duration from PR approval to merging. |
 | `Time to Deploy`       | Duration from merging to start of deployment. |
 | `Deploy Time`       | Duration from start of deployment to end of deployment. |
+| `Has Failed Jobs` | Boolean indicating whether any CI job execution failed for the commit, including failures that passed after a retry. Requires CI Visibility. |
+| `Has Failed Tests` | Boolean indicating whether any test execution failed because of a non-flaky test in the commit. Requires Test Optimization. |
+| `Has New Flaky Tests` | Boolean indicating whether any new flaky tests were detected in the commit's test sessions. Requires Test Optimization. |
 
 
 

hugo/content/en/incident_response/incident_management/setup_and_configuration/_index.md

@@ -37,6 +37,7 @@ To create an incident type:
     {{< nextlink href="/incident_response/incident_management/post_incident/follow-ups" >}}Follow-ups{{< /nextlink >}}
     {{< nextlink href="/incident_response/incident_management/setup_and_configuration/notification_rules" >}}Notification Rules{{< /nextlink >}}
     {{< nextlink href="/incident_response/incident_management/setup_and_configuration/property_fields" >}}Property Fields{{< /nextlink >}}
+    {{< nextlink href="/incident_response/incident_management/setup_and_configuration/transition_forms" >}}Transition Forms{{< /nextlink >}}
     {{< nextlink href="/incident_response/incident_management/setup_and_configuration/responder_types" >}}Responder Types{{< /nextlink >}}
     {{< nextlink href="/incident_response/incident_management/setup_and_configuration/templates" >}}Templates{{< /nextlink >}}
     {{< nextlink href="/incident_response/incident_management/setup_and_configuration/automations" >}}Automations{{< /nextlink >}}

hugo/content/en/incident_response/incident_management/setup_and_configuration/property_fields.md

@@ -70,11 +70,11 @@ If you mark a field as "Required at Declaration," users are required to enter a
 
 ### Prompt user
 
-Incident Management can be configured to prompt responders to set particular fields when changing the incident's state. To set this behavior for a field, edit the field's "Prompt user" option.
+Incident Management can be configured to prompt responders to set particular fields when changing the incident's state.
 
-**During declaration**: Users are prompted to enter a value for the field during declaration and at all state changes if the field is empty.
+**During declaration**: To prompt responders to enter a value for the field during declaration, edit the field's "Prompt user" option.
 
-**When the incident is moved to Stable/Resolved/Completed**: Users are prompted to enter a value for the field when moving the incident to the selected state and any later state. For example, if you select "When the incident is moved to Stable," users are prompted to fill out the field when moving incidents to Stable, Resolved, or Completed.
+**When the incident is moved to Stable/Resolved/Completed**: To prompt users for a field when an incident moves to a given status, use [transition forms][14].
 
 ### Custom fields in search and analytics
 
@@ -95,3 +95,4 @@ In Incident Management Analytics, number fields appear as measures that can be g
 [11]: /incident_response/incident_management/investigate/declare
 [12]: /incident_response/incident_management/setup_and_configuration/property_fields/#custom-fields-in-search-and-analytics
 [13]: /actions/workflows/
+[14]: /incident_response/incident_management/setup_and_configuration/transition_forms

hugo/content/en/incident_response/incident_management/setup_and_configuration/transition_forms.md

@@ -0,0 +1,28 @@
+---
+title: Transition Forms
+description: Prompt incident responders to fill out specific fields on status changes.
+---
+
+## Overview
+
+Any time an incident progresses through status changes, you can guide responders to fill out fields on the incident with transition forms. These forms help ensure that information about the incident is collected at the right time in the incident response process.
+
+{{< img src="/incident_response/incident_management/setup_and_configuration/status_transition_form.png" alt="Status Change form prompting the user to fill out the required Teams and Postmortem Owner fields when moving an incident to Resolved" style="width:70%;" >}}
+
+## Prerequisites
+
+To set up transition forms, you must have the `Incident Settings Write` permission. For more information, see [Datadog Role Permissions][1].
+
+## Configure a transition form
+
+1. In Datadog, navigate to **Incidents** > [**Settings**][2].
+1. Under **Incident Types**, expand an incident type to edit.
+1. Click the **Transition Forms** tab.
+1. Select the status you want to configure.
+1. Choose which fields appear on the form. You can add [property fields][3] and [responder types][4]. Any field can be marked as required or optional.
+1. Click **Save**.
+
+[1]: /account_management/rbac/permissions/#case-and-incident-management
+[2]: https://app.datadoghq.com/incidents/settings
+[3]: /incident_response/incident_management/setup_and_configuration/property_fields
+[4]: /incident_response/incident_management/setup_and_configuration/responder_types

hugo/content/en/incident_response/on-call/pages/live_call_routing.md

@@ -61,7 +61,9 @@ Responders then have the following options:
 
 #### Escalation logic
 
-For direct call routing, escalation proceeds as follows:
+For direct call routing, On-Call calls the responders in each step of the escalation policy. If no one answers, On-Call immediately advances to the next step and calls its responders. It does not wait for the delay configured between steps, helping connect the caller to an available responder as quickly as possible.
+
+Escalation proceeds as follows:
 
 - **Multiple responders at the same level**: All responders are called simultaneously. The first to answer is connected.
 - **Responder rejects a call**: The system immediately escalates to the next responder.

hugo/content/en/incident_response/work_management/ai/_index.md

@@ -5,12 +5,9 @@ aliases:
 - /service_management/case_management/mcp_server/
 - /incident_response/case_management/mcp_server/
 - /incident_response/case_management/ai/
+site_support_id: work_management_ai_site_support
 ---
 
-{{< site-region region="gov" >}}
-<div class="alert alert-danger">AI features for Work Management are not supported for your selected <a href="/getting_started/site">Datadog site</a> ({{< region-param key="dd_site_name" >}}).</div>
-{{< /site-region >}}
-
 Datadog Work Management lets you assign work items to AI agents alongside people. It integrates with the Datadog MCP Server and custom agents built with Bits Agent Builder to automate work item triage, assignment, and resolution.
 
 ## MCP Server

hugo/content/en/integrations/_index.md

@@ -18,8 +18,6 @@ aliases:
     - /integrations/coreos/
     - /integrations/ubuntu/
     - /integrations/amazon-opsworks/
-    - /integrations/salesforce_incidents/
-    - /integrations/salesforce-incidents/
 description: Gather data from all of your systems, apps, & services
 algolia:
     tags: ['integration', 'integration setup']

hugo/content/en/llm_observability/build_with_ai/mcp_server.md

@@ -409,6 +409,44 @@ The `llmobs` toolset includes the following tools:
 `get_llmobs_pattern_points`
 : Get a cursor-paginated page of clustering points (individual spans) assigned to a single topic. Each point includes the `span_id`, `session_id`, and a span input preview. Pass `next_page_token` back as `page_token` to continue paging.
 
+### Annotation queue tools
+
+`list_llmobs_annotation_queues`
+: List all [annotation queues][10] for the org.
+
+`create_llmobs_annotation_queue`
+: Create an annotation queue for human review of traces, optionally defining its label schema at creation time.
+
+`update_llmobs_annotation_queue`
+: Update an annotation queue's name, description, or label schema.
+
+`delete_llmobs_annotation_queue`
+: Delete an annotation queue.
+
+`get_llmobs_annotation_label_schema`
+: Get the label schema for an annotation queue, which defines the labels that annotators apply during review.
+
+`update_llmobs_annotation_label_schema`
+: Create or replace the label schema for an annotation queue.
+
+`add_llmobs_annotation_queue_interactions`
+: Add one or more traces to an annotation queue for review.
+
+`delete_llmobs_annotation_queue_interactions`
+: Remove traces from an annotation queue.
+
+`get_llmobs_annotated_interactions`
+: Get the annotated interactions in an annotation queue along with the labels that annotators applied to them.
+
+`get_llmobs_annotations_by_content_ids`
+: Get the annotations applied to specific traces or sessions by their content IDs.
+
+`upsert_llmobs_annotations`
+: Create or update the annotations applied to interactions in a queue.
+
+`delete_llmobs_annotations`
+: Delete annotations applied to interactions in a queue.
+
 ## Recommended workflows
 
 ### Trace analysis
@@ -492,3 +530,4 @@ For custom visualizations that go beyond standard Datadog widgets, like comparis
 [7]: /account_management/org_settings/service_accounts/
 [8]: https://github.com/datadog-labs/agent-skills
 [9]: /llm_observability/build_with_ai/claude_code_skills
+[10]: /llm_observability/investigate/annotation_queues

hugo/content/en/monitors/notify/_index.md

@@ -91,6 +91,11 @@ An @notification must have a space between it and the last line character:
 {{% notifications-email %}}
 {{% /collapse-content %}}
 
+### Threading notifications in Slack
+Monitor notifications sent to Slack through [notification rules][22] can be threaded. When threading is enabled, all monitor alerts for a given alert cycle are grouped under a single Slack thread, with the top-level message reflecting the latest status of the monitor. To enable monitor threading, set up or edit a [notification rule][22] scoped to the monitor alerts you want to target. Select Thread Notifications and save.
+
+**Note**: An alert cycle is defined as starting from a non-recovered state to a recovered state. 
+
 ### Bulk editing monitor @-handles
 Datadog supports editing alert message recipients across multiple monitors at once. Use this feature to efficiently add, remove, or replace `@-handles` in the monitor message body. Use cases include:
 

hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_standalone.md

@@ -768,6 +768,18 @@ To apply later changes, run `helm upgrade node-collector open-telemetry/opentele
 {{% /tab %}}
 {{< /tabs >}}
 
+## Install the core Datadog Agent alongside DDOT
+
+If you want to run the core Datadog Agent on the same nodes as the standalone DDOT Collector—for example, to collect infrastructure metrics, APM, or logs through the core Agent while DDOT handles OTLP ingestion—you can install it separately using the [Datadog Operator][57].
+
+By default, the Datadog Operator Helm chart watches <code>DatadogAgent</code> resources only in the namespace where the Operator is installed (<code>watchNamespaces: []</code>). If the <code>DatadogAgent</code> resource is in a different namespace than the Operator, for example, to keep it separate from the <code>OpenTelemetryCollector</code> resource's namespace, set <code>watchNamespaces</code> to include the namespace where the <code>DatadogAgent</code> resource is created:
+<pre><code>helm upgrade datadog-operator datadog/datadog-operator \
+  -n &lt;OPERATOR_NAMESPACE&gt; \
+  --reuse-values \
+  --set 'watchNamespaces[0]=&lt;DATADOG_AGENT_NAMESPACE&gt;'
+</code></pre>
+If the Operator doesn't watch the namespace where the <code>DatadogAgent</code> resource is created, the resource silently fails to reconcile, with no error, no Kubernetes event, and no status update to indicate the problem.
+
 ## Send your telemetry to Datadog
 
 To send your telemetry data to Datadog:
@@ -905,3 +917,4 @@ View metrics from the DDOT Collector to monitor the Collector health.
 [54]: https://helm.sh
 [55]: https://opentelemetry.io/docs/platforms/kubernetes/operator/
 [56]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
+[57]: /getting_started/containers/datadog_operator/