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 [e-mail]). 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.