> For the complete documentation index, see [llms.txt](https://docs.soda.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.soda.io/quickstart.md).

# Quickstart

This quickstart shows how Soda **detects unexpected data issues** by leveraging AI powered Anomaly Detection and **prevents future problems** by using data contracts.

### Scenario

A data engineer at a retail company needs to maintain the `regional_sales` dataset so their team can manage regional sales data from hundreds of stores across the country. The dataset feeds executive dashboards and downstream ML models for inventory planning. Accuracy and freshness are critical, so you need both:

* **Automated anomaly detection** on key metrics (row counts, freshness, schema drift)
* **Proactive enforcement** of business rules via data contracts

### Sign up

> Contact us at <support@soda.io> to get an account set up.

After signing up, you can follow the steps below to set up a data source and start improving data quality.

### Add a Data Source

Soda AI, paired with Soda Cloud’s no-code UI, lets you **connect** to any data source, **onboard** datasets, and **monitor** results in minutes.

{% stepper %}
{% step %}

#### Establish connection

Navigate to the **Data Sources** > Create a **New data source**

**F**ill out the connection details. Then, click on **Connect**.

<figure><img src="/files/Cynw5IwruVPmWJKXl3nB" alt="" width="375"><figcaption></figcaption></figure>

> Learn more details on how to [Onboard data sources & datasets](/onboard-data-sources-and-datasets.md).
> {% endstep %}

{% step %}

#### Onboard datasets

You can onboard datasets by asking **Soda AI** to do it for you.

<figure><img src="/files/1RJSnC9y7EZQ8lCTl5pB" alt="" width="298"><figcaption></figcaption></figure>

> If you prefer to onboard datasets manually, head to the [onboarding page](/onboard-data-sources-and-datasets/onboard-datasets-on-soda-cloud.md#onboard-datasets).
> {% endstep %}

{% step %}

#### Enable Metric Monitoring

You can enable Metric Monitoring in several ways:

* While [manually onboarding](/onboard-data-sources-and-datasets/onboard-datasets-on-soda-cloud.md)
* By navigating to the dataset > **Metric Monitoring** tab
* By asking Soda AI to enable Metric Monitoring

{% hint style="info" %}
If you onboarded the dataset via Soda AI, the **dataset page** won't show any monitors yet.
{% endhint %}

Soda AI can **enable Metric Monitoring** for you:

<figure><img src="/files/98kEV4OJ32WKRvhTGhG6" alt="" width="447"><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

***

### 1. Review Anomaly Detection results

Congratulations, you’ve onboarded your first dataset! Now let’s make sure you always know what’s happening with it.

That’s where Metric Monitoring comes in. It automatically tracks key metrics like volume, freshness, and schema changes, with no manual setup required. You’ll spot anomalies, detect trends, and catch unexpected shifts before they become problems.

{% stepper %}
{% step %}

#### Open the Metric Monitors dashboard

{% stepper %}
{% step %}
Go to **Datasets** → select the dataset to inspect.

<figure><img src="/files/idKlM5lo1o9xKejRTuoG" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
Navigate to the **Metric Monitors** tab to learn more about the metrics calculated.

If enabled, key metrics are automatically monitored by default, helping you detect pipeline issues, data delays, and unexpected structural changes as they happen.

<figure><img src="/files/vzsf89vQcNqdHzwdTCQU" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}
{% endstep %}

{% step %}

#### View anomalies in a specific monitor

In this guide, we will focus on the **Most recent timestamp** monitor. The panel shows that it was expected to be in a range of **0 - 5m 31s**, but the recorded value at scan time was **56m 49s**. In order to take a closer look:

{% stepper %}
{% step %}
Click the **Most recent timestamp** (or monitor of your choice) block.

<figure><img src="/files/madB4Ay75F8RJeJoG9Rf" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
In the monitor page you’ll see:

* any red-dot anomalies flagged by the model,
* measured value vs. expected range,
* buttons to **Mark as expected**, **Create new incident**, etc.
  {% endstep %}

{% step %}
Flag an outlier as "expected" or investigate it further.
{% endstep %}
{% endstepper %}
{% endstep %}
{% endstepper %}

**Soda’s anomaly detection engine was built in-house** (no third-party libraries) and optimized for high precision. It continuously adapts to your data patterns, and it incorporates your feedback to reduce false alarms. Designed to minimize false positives and missed detections, it shows a 70% improvement in detecting anomalous data quality metrics compared to Facebook Prophet across hundreds of diverse, internally curated datasets containing known data quality issues.

The Anomaly Detection Algorithm offers complete control and transparency in the modeling process to allow for interpretability and adaptations. It features high accuracy while leveraging historical data, delivering improvements over time.

### 2. Attack the Issues at Source (No-Code)

Our automated anomaly detection has just done the heavy lifting for you, identifying unusual patterns and potential data issues without any setup required.

But to prevent those issues from happening again, you must define exactly what your data should look like; every column, every rule, every expectation.

That’s where **Data Contracts** come in. They let you proactively set the standards for your data, so problems like this are flagged or even prevented before they impact your business.

{% stepper %}
{% step %}

#### Create a Data Contract

Create a new data contract to define and enforce data quality expectations.

{% stepper %}
{% step %}
In your **Dataset Details** page, go to the **Checks** tab.
{% endstep %}

{% step %}
Click **Create Contract**.

<figure><img src="/files/cJnsl9o7uiFENeZ1BE2v" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
Build a **data contract**.

When creating a data contract, Soda will connect to your dataset and build a data contract template based on the dataset schema. From this point, you can start adding both dataset-level checks and column-level checks, as well as defining a verification schedule or a partition.

<figure><img src="/files/Tz8vH3FCiyr5Yct7VH17" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
Toggle **View Code** if you’d like to inspect the generated SodaCL/YAML. This gives you access to the full contract code.

<figure><img src="/files/fc4JznC5d6RMQytCBAfR" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
You can copy the following full example, paste it into the editor and edit it as you wish. You can toggle back to no-code view to see and edit the checks in the no-code editor.

<details>

<summary>Data contract example</summary>

{% code title="" %}

```yaml
dataset: databricks_demo/unity_catalog/demo_sales_operations/regional_sales
filter: |
  order_date >= ${var.start_timestamp}
  AND order_date < ${var.end_timestamp}
variables:
  start_timestamp:
    default: DATE_TRUNC('week', CAST('${soda.NOW}' AS TIMESTAMP))
  end_timestamp:
    default: DATE_TRUNC('week', CAST('${soda.NOW}' AS TIMESTAMP)) + INTERVAL '7 days'
checks:
  - row_count:
  - schema:
columns:
  - name: order_id
    data_type: INTEGER
    checks:
      - missing:
          name: Must not have null values
  - name: customer_id
    data_type: INTEGER
    checks:
      - missing:
          name: Must not have null values
  - name: order_date
    data_type: DATE
    checks:
      - missing:
          name: Must not have null values
      - failed_rows:
          name: Cannot be in the future
          expression: order_date > DATE_TRUNC('day', CAST('${soda.NOW} ' AS TIMESTAMP)) +
            INTERVAL '1 day'
          threshold:
            must_be: 0
  - name: region
    data_type: VARCHAR
    checks:
      - invalid:
          valid_values:
            - North
            - South
            - East
            - West
          name: Valid values
  - name: product_category
    data_type: VARCHAR
  - name: quantity
    data_type: INTEGER
    checks:
      - missing:
          name: Must not have null values
      - invalid:
          valid_min: 0
          name: Must be higher than 0
  - name: price
    data_type: NUMERIC
    checks:
      - invalid:
          valid_min: 0
          name: Must be higher than 0
      - missing:
          name: Must not have null values
  - name: payment_method
    data_type: VARCHAR
    checks:
      - missing:
          name: Must not have null values
      - invalid:
          threshold:
            metric: count
            must_be: 0
          filter: region <> 'north'
          valid_values:
            - PayPal
            - Bank Transfer
            - Cash
            - Credit Card
          name: Valid values in all regions except North
      - invalid:
          name: Valid values in North
          filter: region = 'north'
          valid_values:
            - PayPal
            - Bank Transfer
            - Credit Card
          qualifier: ABC124

```

{% endcode %}

</details>
{% endstep %}
{% endstepper %}

That’s right: with Soda, you can edit a contract using either a **no-code interface** or **directly in code**. This ensures an optimal experience for all users while also providing a version-controlled code format that can be synced with a Git repository.
{% endstep %}

{% step %}

#### Publish & verify

{% stepper %}
{% step %}
Click **Test** to verify the contract executes as expected
{% endstep %}

{% step %}
When you are done with the contract, click **Publish**

<figure><img src="/files/UT7nVNVXYR4RWk8aTaLM" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
Click **Verify**. Soda will evaluate your rules against the current data.

<figure><img src="/files/JJRQhf1AHoxsZiYydJC5" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}
{% endstep %}

{% step %}

#### Review check results

Review the outcomes of the contract checks to confirm whether the data meets expectations.

You can drill into those failures in the **Checks** tab.

<figure><img src="/files/4CcsAASioQEMsEFUP0Z8" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

### 3. Attack the Issues at Source (Code)

You can trigger contract verification programmatically as part of your pipeline, so your data gets tested every time it runs.

We’ve prepared an example notebook to show you how it works:

Open the following Notebook example: <https://colab.research.google.com/drive/1zkV_2tLJ4ohdzmKGS3LgdFDDnTNTUXew?usp=sharing>

{% stepper %}
{% step %}
In your Python environment, first install the Soda Core library

```sh
pip install -i https://pypi.cloud.soda.io/simple -U soda-core
```

{% endstep %}

{% step %}
Create a YAML file

In the same environment, create a `sc_config.yml` file that contains your API keys, which are necessary to connect to Soda Cloud. You can get your API keys from your Profile: [Generate API keys](/reference/soda-apis/generate-api-keys.md)

The `sc_config.yml` file should look like the following:

{% code title="sc\_config.yml" %}

```yaml
soda_cloud:
  host: cloud.soda.io                ## Or cloud.us.soda.io
  api_key_id: YOUR_API_KEY_ID        ## Replace with your actual key ID
  api_key_secret: YOUR_API_KEY_ID    ## Replace with your actual key secret
```

{% endcode %}
{% endstep %}

{% step %}
Trigger contract verification

Now you are ready to trigger the verification of the contract. To do that just provide:

* the identifier of your dataset
* the path to the configuration file you just created in the previous step

This will trigger a verification using Soda Runner and return the logs.

**Create a `verify_contract.py` file** in your environment with the code below (or run it from a Jupyter notebook/Python interpreter):

```python
from soda_core import configure_logging
from soda_core.contracts import verify_contracts_on_runner

configure_logging(verbose=False)

res = verify_contracts_on_runner(
    dataset_identifiers=["databricks_demo/unity_catalog/demo_sales_operations/regional_sales"],
    soda_cloud_file_path="sc_config.yml",
)


print(res.get_logs())
```

> You can learn more about the Python API here: [Python API](/reference/soda-apis/python-api.md)
> {% endstep %}
> {% endstepper %}

<i class="fa-hexagon-check" style="color:$success;">:hexagon-check:</i> **You’ve completed the verification and are now ready to start catching data quality issues with Soda**

### What’s Next?

* Explore [**Profiling**](/data-observability/profiling.md) in the **Discover** tab to curate column selections for deeper analysis.
* Set up [**Notification Rules**](/manage-issues/notifications.md) (bell icon → **Add Notification Rule**) to push alerts to Slack, Jira, PagerDuty, etc.
* Dive into [**Custom Monitors**](/data-observability/metric-monitoring-dashboard/custom-monitors.md) via `scan.yml` or the UI for even more tailored metrics.

***

{% hint style="info" %}
You are **not logged in to Soda** and are viewing the default public documentation. Learn more about [Licensing & documentation access](/reference/documentation-access-and-licensing.md).

If you do have a Soda license, make sure to **log in to Soda Cloud in this same browser**.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.soda.io/quickstart.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.