row count anomaly fires on every holiday because calendar table is stale failure

TL;DR

Teach the anomaly check the calendar: row counts legitimately collapse on holidays, and a stale calendar table makes the model treat the holiday as a normal day, so update the calendar and mark holidays as expected-low days. The check fires because its expectation of a normal day is wrong on holidays, and it is wrong because the calendar it consults has not been maintained for the current year.

row count anomaly fires on every holiday because calendar table is stale failure

Use this when

• The check or run fails with this symptom: a row count anomaly fires on every holiday because the calendar table is stale.
• You are working on a volume or anomaly check that adjusts expectations using a business calendar table and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A drop on a day that is not a holiday in the operating region, which is a real anomaly the calendar should not excuse.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List the days the anomaly fired and match them against public holidays for the operating regions. Verify: every firing day is a holiday, or one is not and needs separate investigation
2. Check the calendar table coverage for the current and next year. Verify: the calendar ends before the recent holidays
3. Regenerate or extend the calendar with the correct regional holidays, including observed days for weekends. Verify: the calendar covers the next twelve months
4. Configure the check to use the calendar, either excluding holidays or applying the holiday expectation band. Verify: a replay over the last holiday shows no alert
5. Add a yearly task to refresh the calendar before it lapses. Verify: the refresh is scheduled with an owner

Variant phrasings

row count anomaly fires every holiday calendar stale

The shorter phrasing focused on the named failure.

anomaly alert holiday false positive calendar table

The symptom phrasing a searcher tries next.

volume anomaly holiday calendar table fix

The variant naming the failing stage or tool directly.

Compatibility: Anomaly checks in Elementary, Monte Carlo, and custom volume monitors with calendar awareness

Why it happens

Calendar tables are loaded once and forgotten. When coverage runs out, holiday logic silently stops applying, and seasonal volume drops that the system used to excuse become anomalies, eroding trust in every other alert from the same check.

Edge cases / pitfalls

• Multi-region operations need the union and the intersection of regional holidays handled deliberately; one region holiday rarely zeroes global volume.
• A stale calendar can also hide real anomalies on days wrongly marked as holidays; audit the calendar, do not just extend it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ftj6JZQBkQh63GYMB5hotA

Resolved from the public thread: https://vectle.com/posts/pst_ftj6JZQBkQh63GYMB5hotA

Thread query: row count anomaly fires on every holiday because calendar table is stale failure

TL;DR: Teach the anomaly check the calendar: row counts legitimately collapse on holidays, and a stale calendar table makes the model treat the holiday as a normal day, so update the calendar and mark holidays as expected-low days. The check fires because its expectation of a normal day is wrong on holidays, and it is wrong because the calendar it consults has not been maintained for the current year.