[pull] master from DataDog:master

content/en/api/v2/observability-pipelines/request.ValidatePipeline_1238441879.json

@@ -0,0 +1,55 @@
+{
+  "data": {
+    "attributes": {
+      "config": {
+        "destinations": [
+          {
+            "id": "clickhouse-destination",
+            "inputs": [
+              "my-processor-group"
+            ],
+            "type": "clickhouse",
+            "table": "application_logs",
+            "database": "my_database",
+            "compression": "gzip",
+            "auth": {
+              "strategy": "basic",
+              "username_key": "CLICKHOUSE_USERNAME",
+              "password_key": "CLICKHOUSE_PASSWORD"
+            },
+            "batch": {
+              "max_events": 1000,
+              "timeout_secs": 1
+            }
+          }
+        ],
+        "processor_groups": [
+          {
+            "enabled": true,
+            "id": "my-processor-group",
+            "include": "service:my-service",
+            "inputs": [
+              "datadog-agent-source"
+            ],
+            "processors": [
+              {
+                "enabled": true,
+                "id": "filter-processor",
+                "include": "status:error",
+                "type": "filter"
+              }
+            ]
+          }
+        ],
+        "sources": [
+          {
+            "id": "datadog-agent-source",
+            "type": "datadog_agent"
+          }
+        ]
+      },
+      "name": "Pipeline with ClickHouse Destination"
+    },
+    "type": "pipelines"
+  }
+}

content/en/api/v2/observability-pipelines/request.ValidatePipeline_337125830.json

@@ -0,0 +1,50 @@
+{
+  "data": {
+    "attributes": {
+      "config": {
+        "destinations": [
+          {
+            "id": "datadog-logs-destination",
+            "inputs": [
+              "my-processor-group"
+            ],
+            "type": "datadog_logs"
+          }
+        ],
+        "processor_groups": [
+          {
+            "enabled": true,
+            "id": "my-processor-group",
+            "include": "service:my-service",
+            "inputs": [
+              "websocket-source"
+            ],
+            "processors": [
+              {
+                "enabled": true,
+                "id": "filter-processor",
+                "include": "status:error",
+                "type": "filter"
+              }
+            ]
+          }
+        ],
+        "sources": [
+          {
+            "id": "websocket-source",
+            "type": "websocket",
+            "decoding": "json",
+            "auth_strategy": "bearer",
+            "token_key": "WS_BEARER_TOKEN",
+            "uri_key": "WS_URI",
+            "tls": {
+              "mode": "enabled"
+            }
+          }
+        ]
+      },
+      "name": "Pipeline with WebSocket Source"
+    },
+    "type": "pipelines"
+  }
+}

content/en/api/v2/observability-pipelines/request.ValidatePipeline_620504950.json

@@ -0,0 +1,60 @@
+{
+  "data": {
+    "attributes": {
+      "config": {
+        "destinations": [
+          {
+            "id": "clickhouse-destination",
+            "inputs": [
+              "my-processor-group"
+            ],
+            "type": "clickhouse",
+            "table": "application_logs",
+            "database": "my_database",
+            "format": "arrow_stream",
+            "batch_encoding": {
+              "codec": "arrow_stream",
+              "allow_nullable_fields": false
+            },
+            "compression": "gzip",
+            "auth": {
+              "strategy": "basic",
+              "username_key": "CLICKHOUSE_USERNAME",
+              "password_key": "CLICKHOUSE_PASSWORD"
+            },
+            "batch": {
+              "max_events": 1000,
+              "timeout_secs": 1
+            }
+          }
+        ],
+        "processor_groups": [
+          {
+            "enabled": true,
+            "id": "my-processor-group",
+            "include": "service:my-service",
+            "inputs": [
+              "datadog-agent-source"
+            ],
+            "processors": [
+              {
+                "enabled": true,
+                "id": "filter-processor",
+                "include": "status:error",
+                "type": "filter"
+              }
+            ]
+          }
+        ],
+        "sources": [
+          {
+            "id": "datadog-agent-source",
+            "type": "datadog_agent"
+          }
+        ]
+      },
+      "name": "Pipeline with ClickHouse Destination Arrow Stream"
+    },
+    "type": "pipelines"
+  }
+}

content/en/containers/autoscaling/_index.md

@@ -232,8 +232,8 @@ There are three ways to enable autoscaling for a workload. Pick the path that ma
 The fastest way to get started is the [Setup page][11] in the Datadog UI. The wizard walks you through five steps: select a cluster, verify Agent and permission requirements, choose an install method, pick a scaling template, and deploy. Templates available in the wizard:
 
 - **Optimize cost**: high CPU utilization target, aggressive scale-down, lowest replica floor. Best for stateless, cost-sensitive workloads.
-- **Optimize balance**: moderate utilization target, balanced scale-up and scale-down. Best for most stateless workloads.
-- **Optimize performance**: conservative utilization target, slow scale-down, higher replica floor. Best for stateful or critical services.
+- **Optimize balance**: moderate utilization target, fast scale-up, balanced scale-down. Best for most stateless workloads.
+- **Optimize performance**: conservative utilization target, fast scale-up, slow scale-down, higher replica floor. Best for stateful or critical services.
 - **Customize**: start from any of the above and tune CPU target, replicas, and stabilization windows yourself.
 
 The Setup wizard is best for trying autoscaling on a single workload, getting hands-on with a recommendation, or onboarding a small set of workloads. (Requires `Workload Scaling Write` and `Autoscaling Manage` permissions.)
@@ -282,7 +282,7 @@ spec:
                 - periodSeconds: 120
                   type: Percent
                   value: 50
-            stabilizationWindowSeconds: 300
+            stabilizationWindowSeconds: 190
         update:
             strategy: Auto
     constraints:
@@ -302,7 +302,7 @@ spec:
 {{% /tab %}}
 {{% tab "Optimize Balance" %}}
 
-Pick this template when you want savings without trading off availability. It's a sensible default for most stateless workloads. The defining setting is the moderate CPU utilization target (70%) paired with a conservative scale-down (20% every 20 minutes) and a two-replica minimum. The controller adds capacity rapidly but removes it slowly.
+Pick this template when you want savings without trading off availability. It's a sensible default for most stateless workloads. The defining setting is the moderate CPU utilization target (70%) paired with a conservative scale-down and a two-replica minimum. The controller adds capacity rapidly but removes it slowly.
 
 ```yaml
 apiVersion: datadoghq.com/v1alpha2
@@ -330,7 +330,7 @@ spec:
                 - periodSeconds: 120
                   type: Percent
                   value: 50
-            stabilizationWindowSeconds: 600
+            stabilizationWindowSeconds: 130
         update:
             strategy: Auto
     constraints:
@@ -417,7 +417,7 @@ spec:
                 - periodSeconds: 120
                   type: Percent
                   value: 50
-            stabilizationWindowSeconds: 600
+            stabilizationWindowSeconds: 130
         # Vertical updates disabled — horizontal only
         update:
             strategy: Disabled
@@ -472,9 +472,9 @@ The Cluster Agent ships three built-in profiles and recreates them on startup, s
 
 | Profile | CPU target | Min replicas | Profile of behavior |
 |---|---|---|---|
-| `datadog-optimize-cost` | 85% | 1 | Stateless, cost-sensitive workloads. Fast scale-up and scale-down (5-minute stabilization windows, 50% step every 2 minutes). |
-| `datadog-optimize-balance` | 70% | 2 | Default for most stateless workloads. Balanced 10-minute stabilization windows, conservative scale-down (20% step every 20 minutes). |
-| `datadog-optimize-performance` | 60% | 3 | Stateful or latency-sensitive workloads. Very conservative scale-down (15-minute stabilization windows, 10% step every 30 minutes). |
+| `datadog-optimize-cost` | 85% | 1 | High CPU utilization target, aggressive scale-down, lowest replica floor. Best for stateless, cost-sensitive workloads. |
+| `datadog-optimize-balance` | 70% | 2 | Moderate utilization target, fast scale-up, balanced scale-down. Best for most stateless workloads. |
+| `datadog-optimize-performance` | 60% | 3 | Conservative utilization target, fast scale-up, slow scale-down, higher replica floor. Best for stateful or critical services. |
 
 To activate a profile on a single workload, add the label to the workload's `metadata.labels`:
 
@@ -515,7 +515,7 @@ spec:
     applyPolicy:
       mode: Apply
       scaleUp:
-        stabilizationWindowSeconds: 300
+        stabilizationWindowSeconds: 190
         rules:
           - type: Percent
             value: 50

content/en/containers/guide/manage-datadogpodautoscaler-with-argocd.md

@@ -287,7 +287,7 @@ autoscaler:
       - type: Percent
         value: 50
         periodSeconds: 120
-    stabilizationWindowSeconds: 600
+    stabilizationWindowSeconds: 130
     strategy: Max
   scaleDown:
     rules:

content/en/containers/guide/manage-datdadogpodautoscaler-with-terraform.md

@@ -318,7 +318,7 @@ resource "kubernetes_manifest" "datadogpodautoscaler_nginx_dka_demo_nginx" {
               "value" = 50
             },
           ]
-          "stabilizationWindowSeconds" = 600
+          "stabilizationWindowSeconds" = 130
           "strategy" = "Max"
         }
         "update" = {

content/en/incident_response/status_pages/_index.md

@@ -20,7 +20,7 @@ further_reading:
 
 ## Overview
 
-{{< img src="service_management/status_pages/shopist_status_page3.png" alt="Example status page showing service components with their current status and recent incident updates" style="width:100%;" >}}
+{{< img src="incident_response/status_pages/shopist_status_page3.png" alt="Example status page showing service components with their current status and recent incident updates" style="width:100%;" >}}
 
 Status Pages is part of Datadog's Incident Response suite, alongside On-Call and Incident Management. It lets your team proactively communicate **service availability**, **incidents**, and **planned maintenance** with customers or internal stakeholders through a shareable web page.
 
@@ -90,7 +90,7 @@ To create, update, or publish Status Pages, you must have the appropriate RBAC p
 
 ## Add components
 
-{{< img src="/service_management/status_pages/status_page_components.png" alt="Status page component configuration with live preview panel" style="width:100%;" >}}
+{{< img src="/incident_response/status_pages/status_page_components.png" alt="Status page component configuration with live preview panel" style="width:100%;" >}}
 
 Components are the building blocks of your status page. Each one represents a service or feature your users care about. Some examples of components include:
 - API Gateway
@@ -138,11 +138,11 @@ If you selected:
 
 Notices are messages published to a status page to communicate system status. Status Pages support two types of notices: **degradations** for unplanned service impact and **maintenance windows** for planned downtime.
 
-{{< img src="service_management/status_pages/select_notice_type_status_page.png" alt="Status page notice type selector with degradation and scheduled maintenance options" style="width:60%;" >}}
+{{< img src="incident_response/status_pages/select_notice_type_status_page.png" alt="Status page notice type selector with degradation and scheduled maintenance options" style="width:60%;" >}}
 
 ### Publish a degradation
 
-{{< img src="service_management/status_pages/shopist_status_page_degradations2.png" alt="Example status page showing service components experience degradation" style="width:100%;" >}}
+{{< img src="incident_response/status_pages/shopist_status_page_degradations2.png" alt="Example status page showing service components experience degradation" style="width:100%;" >}}
 
 Degradation notices communicate **unplanned service impact**, such as incidents or service disruptions. Use degradation notices to keep users informed as an issue is investigated, mitigated, and resolved.
 
@@ -157,7 +157,7 @@ From a status page, click **Publish Notice** and select **Degradation**, then pr
 | **Impact** | Impact level per component: <br>- Operational <br>- Degraded Performance <br>- Partial Outage <br>- Major Outage |
 | **Notify subscribers** | Toggle to send updates to subscribed users |
 
-{{< img src="service_management/status_pages/publish_status_page_degradation_1.png" alt="Example publish notice modal for degradations" style="width:60%;" >}}
+{{< img src="incident_response/status_pages/publish_status_page_degradation_1.png" alt="Example publish notice modal for degradations" style="width:60%;" >}}
 
 After a degradation notice is reviewed and published, it:
 - Appears on the **Status Pages List** under Active Notices.
@@ -179,11 +179,11 @@ From a status page, select the dropdown next to **Publish Notice**, select **Pub
 | **Notice title** | Short, clear description of the incident <br>*Example: Increased error rates in US region* |
 | **Updates** | Exactly two timestamped updates representing the start and end of the degradation. Each update requires a started at timestamp, status (Investigating or Resolved), description, and affected components. |
 
-{{< img src="service_management/status_pages/publish_status_page_backfill_degradation.png" alt="Example publish backfilled notice modal for degradations" style="width:60%;" >}}
+{{< img src="incident_response/status_pages/publish_status_page_backfill_degradation.png" alt="Example publish backfilled notice modal for degradations" style="width:60%;" >}}
 
 ### Schedule a maintenance window
 
-{{< img src="service_management/status_pages/shopist_maintenance_example.png" alt="Example status page showing service components undergoing maintenance" style="width:100%;" >}}
+{{< img src="incident_response/status_pages/shopist_maintenance_example.png" alt="Example status page showing service components undergoing maintenance" style="width:100%;" >}}
 
 Maintenance windows allow you to proactively communicate planned downtime or service impact before it happens. Unlike degradations which are used for unplanned incidents, maintenance windows are scheduled in advance for infrastructure upgrades, system maintenance, database migrations, and other planned work. This allows you to keep customers informed and reduce support volume.
 
@@ -197,7 +197,7 @@ From the status page, click **Schedule Maintenance**, or click **Publish Notice*
 | **Components impacted** | Components affected during the maintenance window |
 | **Notify subscribers** | Toggle to send advance notification to subscribers |
 
-{{< img src="service_management/status_pages/publish_status_page_maintenance.png" alt="Example publish notice modal for maintenance windows" style="width:60%;" >}}
+{{< img src="incident_response/status_pages/publish_status_page_maintenance.png" alt="Example publish notice modal for maintenance windows" style="width:60%;" >}}
 
 After reviewing and scheduling, the maintenance window:
 - Appears under **Upcoming Maintenance** on the status page
@@ -219,15 +219,15 @@ From a status page, select the dropdown next to **Publish Notice**, select **Pub
 | **Notice title** | Clear description of the maintenance activity <br>*Example: Database infrastructure upgrade* |
 | **Updates** | Exactly two timestamped updates representing the start and end of the maintenance window. Each update requires a started at timestamp, status (In Progress or Completed), description, and affected components. |
 
-{{< img src="service_management/status_pages/publish_status_page_backfill_maintenance.png" alt="Example publish backfilled notice modal for maintenance windows" style="width:60%;" >}}
+{{< img src="incident_response/status_pages/publish_status_page_backfill_maintenance.png" alt="Example publish backfilled notice modal for maintenance windows" style="width:60%;" >}}
 
 ## Email subscriptions
 
 Email subscriptions on status pages are **double opt-in**. After entering an email to subscribe, users receive a confirmation email and must click the confirmation link to activate their subscription. During this process, users can choose to receive notifications for the entire status page or select specific components they want to monitor. A preferred timezone can be configured for timestamp formatting within notifications. Users can manage their preferences and update their subscriptions at any time through the subscription management link included in notification emails.
 
 For **internal** status pages, the subscription process is the same, but users must log in to the same Datadog organization to confirm their subscription and receive notifications.
 
-{{< img src="/service_management/status_pages/status_pages_subscription_1.png" alt="Screenshot of the Status Page subscription modal with fields filled out" style="width:70%;" >}}
+{{< img src="/incident_response/status_pages/status_pages_subscription_1.png" alt="Screenshot of the Status Page subscription modal with fields filled out" style="width:70%;" >}}
 
 
 ## Configure a custom email sender domain
@@ -251,7 +251,7 @@ Visitors can subscribe to status page updates in Slack through the **Datadog Sta
 2. Enable **Slack subscriptions**.
 3. (Optional) Under **Slack App Icon**, upload an image to use as the sender avatar on Slack notifications.
 
-{{< img src="service_management/status_pages/status_pages_enable_slack.png" alt="Status page settings showing the Enable Slack subscriptions toggle and the Slack App Icon upload" style="width:80%;" >}}
+{{< img src="incident_response/status_pages/status_pages_enable_slack.png" alt="Status page settings showing the Enable Slack subscriptions toggle and the Slack App Icon upload" style="width:80%;" >}}
 
 Click **Subscribe** on the published page to open a modal with a tab for each enabled subscription type.
 
@@ -262,9 +262,9 @@ From a published page with Slack subscriptions enabled:
 1. Click **Subscribe** and open the **Slack** tab.
 1. (Optional) Select **Subscribe to specific services** to choose individual components, or leave it cleared to follow the entire page.
 1. Click **Subscribe via Slack**.
-   {{< img src="service_management/status_pages/status_pages_slack_subscription_modal.png" alt="Subscribe to Updates modal with the Slack tab selected and a Subscribe via Slack button" style="width:70%;" >}}
+   {{< img src="incident_response/status_pages/status_pages_slack_subscription_modal.png" alt="Subscribe to Updates modal with the Slack tab selected and a Subscribe via Slack button" style="width:70%;" >}}
 1. Authorize the **Datadog Status Pages** app for your workspace and select the channel to receive updates.
-   {{< img src="service_management/status_pages/status_pages_slack_oauth.png" alt="Slack authorization screen granting the Datadog Status Pages app access to a workspace and channel" style="width:70%;" >}}
+   {{< img src="incident_response/status_pages/status_pages_slack_oauth.png" alt="Slack authorization screen granting the Datadog Status Pages app access to a workspace and channel" style="width:70%;" >}}
 
 After subscribing, the selected channel receives a welcome message confirming the subscription.