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

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

Fix this in the anomaly detector by acting on the exact message first: add the missing calendar effects explicitly: weekly seasonality, holiday list for the metric country, and an exclusion or special baseline for known peak days. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

anomaly detector false positive alert storm error after daylight saving time change

Use this when

• The operation in the anomaly detector fails with this exact message: anomaly detector false positive alert storm error after daylight saving time change.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the anomaly detector, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: add the missing calendar effects explicitly: weekly seasonality, holiday list for the metric country, and an exclusion or special baseline for known peak days. Verify: backtest on the last occurrence of the same weekday or holiday and confirm no alert fires.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions or alerts against the source in the anomaly detector so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in the anomaly detector on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

A baseline built from ordinary days cannot describe calendar driven days; the detector compares a holiday or Monday peak against a normal day and calls the difference an anomaly.

Variant phrasings

anomaly detector false positive alert storm error after daylight savin

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: anomaly detector false positive alert storm error after daylight savin

The how-to phrasing for the same failure in the anomaly detector. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the anomaly detector troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the anomaly detector at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

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

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

Thread query: anomaly detector false positive alert storm error after daylight saving time change

TL;DR: Fix this in the anomaly detector by acting on the exact message first: add the missing calendar effects explicitly: weekly seasonality, holiday list for the metric country, and an exclusion or special baseline for known peak days. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Fix this in the anomaly detector by acting on the exact message first: add the missing calendar effects explicitly: weekly seasonality, holiday list for the metric country, and an exclusion or special baseline for known peak days. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

how to fix anomaly detector firing false positives every Monday morning failure

Use this when

• The operation in the anomaly detector fails with this exact message: how to fix anomaly detector firing false positives every Monday morning failure.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the anomaly detector, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: add the missing calendar effects explicitly: weekly seasonality, holiday list for the metric country, and an exclusion or special baseline for known peak days. Verify: backtest on the last occurrence of the same weekday or holiday and confirm no alert fires.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions or alerts against the source in the anomaly detector so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in the anomaly detector on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

A baseline built from ordinary days cannot describe calendar driven days; the detector compares a holiday or Monday peak against a normal day and calls the difference an anomaly.

Variant phrasings

how to fix anomaly detector firing false positives every Monday mornin

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: how to fix anomaly detector firing false positives every Monday mornin

The how-to phrasing for the same failure in the anomaly detector. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the anomaly detector troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the anomaly detector at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

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

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

Thread query: how to fix anomaly detector firing false positives every Monday morning failure

TL;DR: Fix this in the anomaly detector by acting on the exact message first: add the missing calendar effects explicitly: weekly seasonality, holiday list for the metric country, and an exclusion or special baseline for known peak days. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.