> For the complete documentation index, see [llms.txt](https://docs.decube.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decube.io/data-quality-v2/monitor-types/field-health/condition-checks.md).

# Condition Checks

Null, Unique, Zero tests.

These are three separate, simple monitor types grouped together because none of them takes a threshold or a pattern — the rule for what makes a row fail is fixed and built into the check itself. The only thing you configure is how many failures to tolerate.

<figure><img src="https://1779874722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTw0qpCVzfrIXqS4FEg4T%2Fuploads%2FClXrreSI8CTqWVSk0IyO%2Fimage-20260812-022312.png?alt=media&amp;token=4601aa41-2f87-499f-a131-afd1878b47b4" alt=""><figcaption></figcaption></figure>

### Null <a href="#null" id="null"></a>

#### What it does <a href="#what-it-does" id="what-it-does"></a>

Checks that a column doesn't contain too many null (empty or missing) values. Applies to all data types.

#### When to use it <a href="#when-to-use-it" id="when-to-use-it"></a>

* Every row in a `users` table is required to have an email. A daily Null check on the `email` column with zero tolerance means any null value raises an incident.
* Phone numbers are known to be optional at signup, so some missing values are tolerated. A daily Null check on `phone_number` with 10% tolerance only alerts when more than 10% of rows are null.

#### What's configurable <a href="#whats-configurable" id="whats-configurable"></a>

* **Schedule** — fixed recurring, or Manual (requires Full Table Scan if Manual).
* **Scan Method** — Full Table Scan or Incremental Scan.
* **Tolerance** (optional) — how many, or what percentage of, null rows are allowed.

#### Worked example 1 — zero tolerance <a href="#worked-example-1-zero-tolerance" id="worked-example-1-zero-tolerance"></a>

* Asset: `users` table, column `email`
* Tolerance: not set

**Resulting rule:** "An incident will be created when any row fails."

#### Worked example 2 — with tolerance <a href="#worked-example-2-with-tolerance" id="worked-example-2-with-tolerance"></a>

* Asset: `users` table, column `phone_number`
* Tolerance: Percentage — 10%

**Resulting rule:** "An incident will be created when more than 10.0% of the scanned rows fail."

### Unique <a href="#unique" id="unique"></a>

#### What it does <a href="#what-it-does.1" id="what-it-does.1"></a>

Checks that a column doesn't contain too many duplicate values. Applies to all data types.

#### When to use it <a href="#when-to-use-it.1" id="when-to-use-it.1"></a>

* `order_id` in an `orders` table is required to be unique. A daily Unique check with zero tolerance means any duplicate order ID raises an incident.
* Phone numbers may legitimately be shared across accounts — for example, family members — but widespread duplication is suspicious. A daily Unique check on `phone_number` with 10% tolerance allows for some sharing.

#### What's configurable <a href="#whats-configurable.1" id="whats-configurable.1"></a>

Same as Null: Schedule, Scan Method, and Tolerance (optional).

#### Worked example <a href="#worked-example" id="worked-example"></a>

* Asset: `orders` table, column `order_id`
* Tolerance: not set

**Resulting rule:** "An incident will be created when any row fails."

### Zero <a href="#zero" id="zero"></a>

#### What it does <a href="#what-it-does.2" id="what-it-does.2"></a>

Checks that a numeric column doesn't contain too many zero values. Only applies to numeric column types.

#### When to use it <a href="#when-to-use-it.2" id="when-to-use-it.2"></a>

A `unit_price` column in a `products` table should never be 0, since a zero price usually signals a missing or mis-loaded value. A daily Zero check flags any row with a price of 0.

#### What's configurable <a href="#whats-configurable.2" id="whats-configurable.2"></a>

Same as Null and Unique: Schedule, Scan Method, and Tolerance (optional).

#### Worked example <a href="#worked-example.1" id="worked-example.1"></a>

* Asset: `products` table, column `unit_price`
* Tolerance: not set

**Resulting rule:** "An incident will be created when any row fails."

### Notes <a href="#notes" id="notes"></a>

* Changing the schedule or scan method later is a destructive change (it creates a new monitor version). Adjusting only the tolerance value is not.
* These three checks have no threshold and no pattern or value set to configure — the only lever you have, beyond schedule and scan method, is tolerance.