> 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/string-checks.md).
# String Checks
String Length, Regex Match, Regex Not Match tests.
These three monitors apply only to string-type columns (char, varchar, text, and similar).
### String Length
#### What it does
Checks that the length of the text in a column falls within an expected range.
#### When to use it
A business requires usernames in a `users` table to be between 3 and 20 characters. A daily check flags any username shorter or longer than that range as a failing row.
#### What's configurable
* **Schedule** — fixed recurring, or Manual (requires Full Table Scan if Manual).
* **Scan Method** — Full Table Scan or Incremental Scan.
* **Threshold** — an Integer Range: a minimum and/or maximum character length. Defines what counts as a failing row. At least one bound is required.
* **Tolerance** (optional) — how many, or what percentage of, failing rows are allowed.
#### Worked example
* Asset: `users` table, column `username`
* Threshold: Integer Range — min 3, max 20
* Tolerance: not set
**Resulting rules:**
* "A row fails when the length of the value in username is below 3 or above 20."
* "An incident will be created when any row fails."
### Regex Match / Regex Not Match
#### What it does
Two variants of the same idea: check whether the text in a column matches, or does not match, a regular expression pattern.
* **Regex Match** — a row fails if its value does not match the pattern. Use this to enforce a required format.
* **Regex Not Match** — a row fails if its value does match the pattern. Use this to forbid a format or pattern.
#### When to use it
* **Regex Match** — A business expects an `email` column to only contain valid emails (a pattern like `user@example.com`). A Regex Match check using an email-format pattern flags any value that doesn't match.
* **Regex Not Match** — A business expects a `name` column to never contain a salutation (Mr, Mrs, Ms, Dr, Prof). A Regex Not Match check using a salutation pattern flags any value that matches — that is, contains a salutation.
#### What's configurable
* **Schedule** — fixed recurring, or Manual (requires Full Table Scan if Manual).
* **Scan Method** — Full Table Scan or Incremental Scan.
* **Pattern** — the regular expression itself. There's no separate Threshold field for these checks — the pattern alone determines whether a row passes or fails.
* **Tolerance** (optional) — how many, or what percentage of, failing rows are allowed.
#### Worked example — Regex Match
* Asset: `users` table, column `email`
* Pattern: `^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$`
* Tolerance: not set
**Resulting rule:** "An incident will be created when any row fails." (A row fails here when its value does not match the pattern.)
#### Worked example — Regex Not Match
* Asset: `users` table, column `name`
* Pattern: `(?i)\b(mr|mrs|ms|dr|prof)\.?\b`
* Tolerance: Percentage — 2%
**Resulting rule:** "An incident will be created when more than 2.0% of the scanned rows fail." (A row fails here when its value matches the pattern — that is, it contains a salutation.)
### Notes
* Changing the schedule or scan method later is a destructive change (it creates a new monitor version).
* Unlike a threshold or tolerance tweak, changing the pattern on a Regex Match or Regex Not Match monitor is also treated as destructive, since it redefines what a passing row looks like. Adjusting only the tolerance value is not destructive.
