> 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/volume.md).

# Volume

Volume monitors check that the number of rows in a table is growing, or shrinking, roughly as expected.

This catches both under-delivery — a pipeline stalled and far fewer rows landed than usual — and over-delivery — a duplicate ingestion run inflated the count.

{% embed url="<https://youtu.be/Yb_ZoxgitWY>" %}

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

* An `events` table ingests clickstream data and is expected to receive between 5,000 and 20,000 new rows every hour. An hourly volume check flags an increment well below the range (a stalled pipeline) or well above it (a possible duplicate ingestion).
* An `orders` fact table is appended to daily and is expected to grow by roughly 10,000–15,000 rows each day. A daily volume check catches days where far fewer rows landed than expected.

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

* **Schedule** — must be a fixed recurring schedule.
* **Detection Method** — how the row count, or the change in row count, is measured:
  * **Column-based** — you pick a timestamp column; the monitor counts how many rows fall between the current and previous scheduled run times. If the column doesn't store timezone information, you also set the UTC offset its values are written in, so the row window lines up with the run times. See [Column timezone](/data-quality-v2/monitors/building-blocks.md#column-timezone).
    * Threshold type available: Count Delta only.
  * **Metadata-based** — pulls the table's total row count directly from the data source's own metadata, then compares this run's total against the previous run's total. Not available for every source or table type.
    * Threshold type available: Count Delta or Percentage Delta.
  * **Full table count** — runs an actual count on the table each run, then compares against the previous run's count.
    * Threshold type available: Count Delta or Percentage Delta.
* **Threshold** — the acceptable range for the row count change:
  * **Count Delta** — a minimum and/or maximum change in row count, for example "between 5,000 and 20,000 more rows." Can be negative, for monitors expecting a table to shrink.
  * **Percentage Delta** — a minimum and/or maximum percentage change, for example "no less than -10% growth." There's no upper cap — a table can grow by more than 100% in one period. Percentage Delta is only available with Metadata-based or Full table count detection, not Column-based.

### Worked example — Count Delta <a href="#worked-example-count-delta" id="worked-example-count-delta"></a>

<figure><img src="https://1779874722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTw0qpCVzfrIXqS4FEg4T%2Fuploads%2FguMgg6P10PsABqI9Tukx%2Fimage-20260811-092827.png?alt=media&amp;token=60a655f0-39c5-49cb-9ff2-af31dfd383fe" alt=""><figcaption></figcaption></figure>

* Asset: `events` table
* Detection Method: Full table count
* Schedule: Every hour
* Threshold: Count Delta — min 5,000, max 20,000

**Resulting rule:** "An incident will be created when the row count change is below 5,000 rows or above 20,000 rows."

### Worked example — Percentage Delta <a href="#worked-example-percentage-delta" id="worked-example-percentage-delta"></a>

<figure><img src="https://1779874722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTw0qpCVzfrIXqS4FEg4T%2Fuploads%2FlMxw5CieMhMmq6YPWr13%2Fimage-20260811-093924.png?alt=media&amp;token=e1f207fa-8d36-449f-89df-98c2ea10604a" alt=""><figcaption></figcaption></figure>

* Asset: `orders` table
* Detection Method: Metadata-based
* Schedule: Daily
* Threshold: Percentage Delta — min -10% (no max set)

**Resulting rule:** "An incident will be created when the growth rate is below -10%."

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

* On the very first run, or if the previous run errored and left no usable data, there's nothing to compare against — the run is simply skipped, not treated as a failure. **This is expected on day one of a new monitor.**
* Changing the schedule or detection method later is a destructive change (it creates a new monitor version). Adjusting only the threshold value — including the threshold nested inside the detection method — is not.