# Sync Observability Settings


This guide explains the settings to configure how RudderStack retains sync logs and snapshot tables for your [Reverse ETL connection]({{< ref "data-pipelines/reverse-etl/developer-guides/retl-connection-setup.md" >}}), and whether it retries failed records in later syncs.

## Sync settings

Access these settings in the **Settings** tab of your Reverse ETL connection:

{{< customreadfile "/includes/retl/sync-observability-settings.md" >}}

## Sync logs

RudderStack supports storing Reverse ETL sync logs in your warehouse. These logs are stored in a certain format in the [RudderStack schema]({{< ref "data-pipelines/reverse-etl/developer-guides/faq.md#rudderstack-schema" >}}) (used for storing the state of each sync). You can explore these logs using SQL or any BI tool to debug any issues or failures during syncs.

{{< warning >}}
Storing the sync logs in your warehouse incurs additional costs.
{{< /warning >}}

## Sync log table schema

The sync log table schema is as follows:

| Column | Description |
| :---| :----|
| `connection_id` | Connection ID for the sync run. |
| `sync_run_id`  | Unique identifier for the sync run. |
| `primary_key` | Value of the primary key column selected for the sync. |
| `operation` | Nature of the operation performed on the row. It can be either `insert`, `update`, or `delete`. |
| `status` | Result of the operation. It can be either `succeeded` or `failed`. |
| `error_reason` | Reason for failure in case `status` is `failed`. |
| `sync_started_at` | Sync start time in UTC. |
| `sync_finished_at` | Sync finish time in UTC. |

## Aborted syncs

When you [stop a running sync]({{< ref "data-pipelines/reverse-etl/developer-guides/start-stop-syncs.md" >}}), the sync stops and is treated as unsuccessful. In the dashboard, this appears as **Aborted**. In the sync log table, records from that run that did not succeed show `status` as `failed`.

The aborted sync does not resume — the next sync starts as a new run rather than picking up where the aborted one left off. Any records that did not sync successfully are handled in subsequent syncs according to your [retry settings](#retry-failed-records).

This differs from syncs interrupted by a system shutdown, for example during a deployment. In that case, the sync is paused safely and resumes from where it stopped once the system is back up.

## Snapshot table schema

RudderStack generates a snapshot table in the [RudderStack schema]({{< ref "data-pipelines/reverse-etl/developer-guides/faq.md#rudderstack-schema" >}}) for each sync. It contains rows (barring invalid rows like duplicate primary keys and null primary keys) from the data source like a warehouse table, view, SQL model, or audience. It also includes the details of the changes that happened in each row during the sync.

{{< warning >}}
Storing the snapshot tables in your warehouse will incur additional costs.
{{< /warning >}}

The snapshot tables are stored in the `snapshot_<connection_id>_<sync_run_id>` format, where: 

- `<connection_id>` is the Reverse ETL [connection ID]({{< ref "data-pipelines/reverse-etl/developer-guides/retl-connection-setup.md#update-mapping-configuration" >}}).
- `<sync_run_id> ` is the unique identifier for the sync run.

{{< image src="images/retl-sources/sync-run-id.webp" alt="RETL connection sync run ID" >}}

The snapshot table schema is as follows:

| Column | Description |
| :---| :----|
| `rudder_operation_type` | Type of operation performed on the row when compared with the last synced data. It can be either `insert`, `update`, or `delete`. | 
| `<column_name>` | Name of the columns selected in the mappings for the sync. |

## Debug issues with sync logs

This section lists some queries you can run on your sync logs for debugging issues in your Reverse ETL syncs.

- Check how a particular primary key has changed over time for a Reverse ETL connection:

```sql
select * from _rudderstack.sync_log where primary_key='<primary_key>' and connection_id='<connection_id>';
```

- Check the data for failures in the sync run:

```sql
SELECT *
FROM   _rudderstack.sync_log sl
       LEFT JOIN
       _rudderstack.snapshot_<connection_id>_<sync_run_id>
       sn
              ON sl.primary_key = sn.<primary_key>
WHERE  sl.sync_run_id = '<sync_run_id>'
       AND sl.status = 'failed'; 
```

{{< warning >}}
Make sure to replace the placeholders in the above queries with the actual values.
{{< /warning >}}

## Retry failed records

The **Retry failed records** toggle in the [sync settings](#sync-settings) lets you determine whether RudderStack should continually retry sending the failed records in the previous syncs to the downstream destination.

{{< info >}}
If a failed record has undergone any changes, RudderStack retries syncing the updated record instead.
{{< /info >}}