> ## Documentation Index > Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt > Use this file to discover all available pages before exploring further. # Overview > What Volume metrics are in Prizm — track the size and quantity of data flowing through an asset to catch pipeline failures early. ## What is a Volume metric? Volume metrics track the **size and quantity of data flowing through an asset**. They are the first line of defence against pipeline failures — a sudden drop in row count or data size is one of the earliest and most reliable signals that something upstream has broken. **Type:** Automatic — Volume metrics are enabled on all connected assets by default as part of the Essential observability profile. No configuration is required to activate them. Volume metrics answer the question: *Is the expected amount of data present?* Prizm establishes a baseline for each Volume metric by observing the asset across multiple operational job runs. Once a baseline is established, anomaly detection flags runs where the value falls outside the expected statistical range. Alerts fire on High and Critical deviations by default. ### Metrics | Metric | Level | Subcategory | Dimension | Description | | --------- | ----- | ----------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Volume | Asset | Volume | Completeness | Computes the total row count of the asset. Tracks volume over time and alerts when row counts drop or spike beyond the expected statistical range. | | Row Count | Asset | Volume | Completeness | Total number of rows in the asset at the time of the last operational job run. A drop to zero almost always indicates a pipeline failure; an unexpected spike can indicate duplicate injection or a runaway load. | | Data Size | Asset | Volume | Completeness | Physical storage footprint of the asset in bytes. A large size increase with no corresponding row increase can indicate JSON column bloat, unintended duplication within rows, or schema changes that added wide columns. | ### How Volume monitoring works Prizm reads the row count and data size of the asset on each operational job run. Both values are trended over time. The statistical model accounts for expected variation — daily load patterns, weekend lulls, end-of-month spikes — and adapts as the asset's normal behavior evolves. Detection is statistical: Prizm computes how many standard deviations the current value is from the historical baseline and triggers alerts at configured deviation thresholds. ### Example use cases **Detecting a failed truncation:** A nightly ETL job truncates and reloads the `fact_orders` table. The row count drops to zero after a failed reload. Prizm fires a Volume alert within the same run — before any downstream dashboard queries the empty table. **Catching duplicate loads:** An Airflow DAG is accidentally triggered twice, loading the same day's records twice. Row count spikes to roughly 2× the expected value. Prizm flags a positive volume anomaly, allowing the data team to remove duplicates before users notice inflated metrics. **Detecting JSON column bloat:** Row count is stable but Data Size triples after a schema change adds a wide `event_payload` JSON column. The size anomaly surfaces the change before it triggers storage quota issues. Volume metrics are most effective when combined with Freshness. A row count within range but a stale Last Updated timestamp means data arrived historically but has not been refreshed recently — a subtler failure pattern that Volume alone would miss. Set thresholds, view the metric detail page, and understand Volume alerts.