STAC-22515: Drop repeat states documentation

SUMMARY.md

@@ -61,7 +61,6 @@
 * [Send health data over HTTP](configure/health/send-health-data/README.md)
   * [Send health data](configure/health/send-health-data/send-health-data.md)
   * [Repeat Snapshots JSON](configure/health/send-health-data/repeat_snapshots.md)
-  * [Repeat States JSON](configure/health/send-health-data/repeat_states.md)
   * [Transactional Increments JSON](configure/health/send-health-data/transactional_increments.md)
 * [Debug health synchronization](configure/health/debug-health-sync.md)
 

configure/health/debug-health-sync.md

@@ -78,7 +78,6 @@ $ sts health status -u urn:health:sourceId:streamId -sub-stream-urn subStreamId3
 {% hint style="info" %}
 A substream status will show the metadata related to the consistency model:
 * **Repeat Snapshots** - Show repeat interval and expiry
-* **Repeat States** - Show repeat interval and expiry
 * **Transactional Increments** - Show checkpoint offset and checkpoint batch index
 {% endhint %}
 

configure/health/health-synchronization.md

@@ -34,7 +34,7 @@ The health synchronization framework works as follows:
 ![Health synchronization pipeline](../../.gitbook/assets/health-sync-pipeline.svg)
 
 ### Consistency models
-SUSE Observability health synchronization relies on different consistency models to guarantee that the data sent from an external monitoring system matches with what SUSE Observability ingests and shows. The consistency model is specified in the `"health"` property of the [common JSON object](/configure/health/send-health-data/send-health-data.md#common-json-object) or as an argument in the SUSE Observability CLI when health data is sent to SUSE Observability. The supported models are: `REPEAT_SNAPSHOTS`, `REPEAT_STATES` and `TRANSACTIONAL_INCREMENTS`. 
+SUSE Observability health synchronization relies on different consistency models to guarantee that the data sent from an external monitoring system matches with what SUSE Observability ingests and shows. The consistency model is specified in the `"health"` property of the [common JSON object](/configure/health/send-health-data/send-health-data.md#common-json-object) or as an argument in the SUSE Observability CLI when health data is sent to SUSE Observability. The supported models are: `REPEAT_SNAPSHOTS` and `TRANSACTIONAL_INCREMENTS`. 
 {% tabs %}
 {% tab title="Repeat snapshots model" %}
 The `REPEAT_SNAPSHOTS` consistency model works with periodic, full snapshots of all checks in an external monitoring system. SUSE Observability keeps track of the checks in each received snapshot and decides if associated external check states need to be created, updated or deleted in SUSE Observability. For example, if a check state is no longer present in a snapshot. This model offers full control over which external checks will be deleted as all decisions are inferred from the received snapshots. There is no ambiguity over the external checks that will be present in SUSE Observability.
@@ -44,14 +44,6 @@ The `REPEAT_SNAPSHOTS` consistency model works with periodic, full snapshots of
 **JSON payload:** The [Repeat Snapshots health payload](/configure/health/send-health-data/repeat_snapshots.md) accepts specific properties to specify when a snapshot starts or stops.
 {% endtab %}
 
-{% tab title="Repeat States model" %}
-The `REPEAT_STATES` consistency model works with periodic checks received from an external monitoring system. SUSE Observability keeps track of the checks and decides if associated external checks need to be created or updated in SUSE Observability. A configurable expiry mechanism is used to delete external checks that aren't observed anymore. This model offers less control over data than the `REPEAT_SNAPSHOTS` model. As an expiry configuration is used to delete external checks, it might happen that elements are deleted due to barely missing the expiry timeout. This would reflect as external checks disappearing and reappearing in SUSE Observability.
-
-**Use this model when:** The external monitoring system isn't capable of collecting all checks in a determined time window. The best effort is just to send the external checks as they're obtained.
-
-**JSON payload:** The [Repeat States health payload](/configure/health/send-health-data/repeat_states.md) accepts specific properties to specify the expiry configuration.
-{% endtab %}
-
 {% tab title="Transactional Increments model" %}
 The `TRANSACTIONAL_INCREMENTS` consistency model is designed to be used on streaming systems where only incremental changes are communicated to SUSE Observability. As there is no repetition of data, data consistency is upheld by ensuring that at-least-once delivery is guaranteed across the entire pipeline. To detect whether any data is missing, SUSE Observability requires that both a checkpoint and the previous checkpoint are communicated together with the `check_states`. This model requires strict control across the whole pipeline to guarantee no data loss.
 

configure/health/send-health-data/send-health-data.md

@@ -43,7 +43,6 @@ Topology, telemetry and health data are sent to the receiver API via HTTP POST.
 SUSE Observability accepts health data based on a chosen [consistency model](/configure/health/health-synchronization.md#consistency-models). The message that can be sent for each model are described on the pages below:
 
 * [Repeat Snapshots JSON](/configure/health/send-health-data/repeat_snapshots.md)
-* [Repeat States JSON](/configure/health/send-health-data/repeat_states.md)
 * [Transactional Increments JSON](/configure/health/send-health-data/transactional_increments.md)
 
 ## See also