Volume anomalies in Snowflake: Large additions, deletions, or lower-than-expected row counts

Issue

Customers may report receiving volume anomaly alerts from their data observability tools (for example, Monte Carlo) related to Snowflake tables.

These alerts can include:

Large additions (more rows added than expected)
Large deletions (fewer rows or temporary data removal)
Lower-than-expected row counts after refresh

Example alerts:

Volume anomaly detected: +125M rows added to [table_name]
Volume anomaly detected: 170M rows deleted from [table_name]
Volume anomaly detected: Row count lower than expected in [table_name]

Such alerts typically occur due to changes in orchestration configuration, upstream query results, or expected system behavior during refresh cycles.


Root Cause

Most volume anomalies are expected outcomes of data refresh operations, rather than system errors.
Common reasons include:

Truncate Table Enabled – The orchestration clears the Snowflake table before every new data load. This can appear as a large deletion followed by a large addition when new data is written.

Upstream Data Variation – Filters, date ranges, or source dataset changes can naturally increase or decrease record counts.

Incremental Load Configuration – If an orchestration is set to load only new or updated records, smaller-than-expected volumes may be observed.


Resolution

Follow these steps to confirm whether the alert represents expected behavior or a true anomaly:

1. Identify the impacted table and orchestration
   Review the alert details to determine which Snowflake table or workflow triggered the anomaly.
2. Under tenant in Amperity check orchestration settings
   Open the corresponding destination orchestration in Amperity.
   Verify whether the “Truncate Table?” option is selected.
   If enabled, temporary deletions and reloads are expected.
   If disabled, needs to be enabled else reach out to support .
3. Review orchestration run history
   Confirm the most recent run succeeded.
   If a failure occurred, validate that the next run restored expected row counts.
4. Escalate if unexpected
   If truncation is not enabled, no upstream changes are found, and record counts remain abnormal after reload → escalate to Amperity Support team.
   
   
   Preventive Guidance

• Be aware that “Truncate Table” will always clear existing data before loading new data.

• Regularly review orchestration run histories to confirm data loads complete successfully.
  
  
  Additional Notes

  Volume anomalies—such as large additions, deletions, or reduced record counts—are often part of normal data-refresh behavior in Amperity workflows.
  If the orchestration completed successfully and the Snowflake table reflects valid data after reload, the alert can generally be marked as expected behavior.

  
  ✅ Example Case:
  A customer reported a significant row-count drop in a Snowflake table. Investigation showed the orchestration had the “Truncate Table” option enabled. The next successful load restored all records, confirming expected behavior.
  In another case, a large addition alert was triggered after upstream datasets expanded due to new data sources—also confirmed as expected.