SLO-3271: Update documentation for the transitions returned by SLO hi…

…story (#2490)

Co-authored-by: ci.datadog-api-spec <packages@datadoghq.com>
Co-authored-by: api-clients-generation-pipeline[bot] <54105614+api-clients-generation-pipeline[bot]@users.noreply.github.com>

.apigentools-info

@@ -4,13 +4,13 @@
     "spec_versions": {
         "v1": {
             "apigentools_version": "1.6.6",
-            "regenerated": "2024-05-14 14:47:49.725473",
-            "spec_repo_commit": "48746015"
+            "regenerated": "2024-05-14 16:40:03.937580",
+            "spec_repo_commit": "45952461"
         },
         "v2": {
             "apigentools_version": "1.6.6",
-            "regenerated": "2024-05-14 14:47:49.743305",
-            "spec_repo_commit": "48746015"
+            "regenerated": "2024-05-14 16:40:03.955222",
+            "spec_repo_commit": "45952461"
         }
     }
 }

.generator/schemas/v1/openapi.yaml

@@ -10661,9 +10661,24 @@ components:
           example: name
           type: string
         history:
-          description: For `monitor` based SLOs, this includes the aggregated history
-            as arrays that include timeseries and uptime data where `0=monitor` is
-            in `OK` state and `1=monitor` is in `alert` state.
+          description: 'The state transition history for the monitor. It is represented
+            as
+
+            an array of pairs. Each pair is an array containing the timestamp of the
+            transition
+
+            as an integer in Unix epoch format in the first element, and the state
+            as an integer in the
+
+            second element. An integer value of `0` for state means uptime, `1` means
+            downtime, and `2` means no data.
+
+            Periods of no data are counted either as uptime or downtime depending
+            on monitor settings.
+
+            See [SLO documentatio](https://docs.datadoghq.com/service_management/service_level_objectives/monitor/#missing-data)
+
+            for detailed information.'
           example:
           - - 1579212382
             - 0
@@ -10843,9 +10858,26 @@ components:
           example: name
           type: string
         history:
-          description: For `monitor` based SLOs, this includes the aggregated history
-            as arrays that include timeseries and uptime data where `0=monitor` is
-            in `OK` state and `1=monitor` is in `alert` state.
+          description: 'The state transition history for `monitor` or `time-slice`
+            SLOs. It is represented as
+
+            an array of pairs. Each pair is an array containing the timestamp of the
+            transition
+
+            as an integer in Unix epoch format in the first element, and the state
+            as an integer in the
+
+            second element. An integer value of `0` for state means uptime, `1` means
+            downtime, and `2` means no data.
+
+            Periods of no data count as uptime in time-slice SLOs, while for monitor
+            SLOs, no data is counted
+
+            either as uptime or downtime depending on monitor settings. See
+
+            [SLO documentation](https://docs.datadoghq.com/service_management/service_level_objectives/monitor/#missing-data)
+
+            for detailed information.'
           example:
           - - 1579212382
             - 0

api/datadogV1/model_slo_history_monitor.go

@@ -17,7 +17,13 @@ type SLOHistoryMonitor struct {
 	Errors []SLOHistoryResponseErrorWithType `json:"errors,omitempty"`
 	// For groups in a grouped SLO, this is the group name.
 	Group *string `json:"group,omitempty"`
-	// For `monitor` based SLOs, this includes the aggregated history as arrays that include timeseries and uptime data where `0=monitor` is in `OK` state and `1=monitor` is in `alert` state.
+	// The state transition history for the monitor. It is represented as
+	// an array of pairs. Each pair is an array containing the timestamp of the transition
+	// as an integer in Unix epoch format in the first element, and the state as an integer in the
+	// second element. An integer value of `0` for state means uptime, `1` means downtime, and `2` means no data.
+	// Periods of no data are counted either as uptime or downtime depending on monitor settings.
+	// See [SLO documentatio](https://docs.datadoghq.com/service_management/service_level_objectives/monitor/#missing-data)
+	// for detailed information.
 	History [][]float64 `json:"history,omitempty"`
 	// For `monitor` based SLOs, this is the last modified timestamp in epoch seconds of the monitor.
 	MonitorModified *int64 `json:"monitor_modified,omitempty"`

api/datadogV1/model_slo_history_sli_data.go

@@ -17,7 +17,14 @@ type SLOHistorySLIData struct {
 	Errors []SLOHistoryResponseErrorWithType `json:"errors,omitempty"`
 	// For groups in a grouped SLO, this is the group name.
 	Group *string `json:"group,omitempty"`
-	// For `monitor` based SLOs, this includes the aggregated history as arrays that include timeseries and uptime data where `0=monitor` is in `OK` state and `1=monitor` is in `alert` state.
+	// The state transition history for `monitor` or `time-slice` SLOs. It is represented as
+	// an array of pairs. Each pair is an array containing the timestamp of the transition
+	// as an integer in Unix epoch format in the first element, and the state as an integer in the
+	// second element. An integer value of `0` for state means uptime, `1` means downtime, and `2` means no data.
+	// Periods of no data count as uptime in time-slice SLOs, while for monitor SLOs, no data is counted
+	// either as uptime or downtime depending on monitor settings. See
+	// [SLO documentation](https://docs.datadoghq.com/service_management/service_level_objectives/monitor/#missing-data)
+	// for detailed information.
 	History [][]float64 `json:"history,omitempty"`
 	// For `monitor` based SLOs, this is the last modified timestamp in epoch seconds of the monitor.
 	MonitorModified *int64 `json:"monitor_modified,omitempty"`