Notice it on Wednesday, not at the end of the month
Almost every costly problem was visible in the data before it became visible in the results.
A decline in a sales channel, a silent increase in returns for a product, a supplier taking longer to deliver, a machine consuming more than usual. These are phenomena that the data records immediately but that the company only discovers at the end of the month, when reporting makes them visible and the damage has already been done.
Anomaly detection reverses this logic: instead of waiting for someone to look at the report, the system monitors continuously and alerts you when something does not add up.
What makes it useful instead of annoying
- It compares against normal, not a fixed threshold: a low sales figure on Monday morning may be normal, while the same figure on Friday afternoon may not be. The reference takes day, seasonality, and trends into account.
- It alerts the right person, with context: not a generic warning, but what changed, by how much, compared with what, and where to look.
- It does not over-alert: a system that sends twenty notifications a day will be ignored within a week, and at that point it is worse than having no system at all.
Two families of checks, used together
- Explicit rules: for what is known and non-negotiable — a value outside the allowed range, a required field left empty, a deviation beyond a defined percentage. Simple, transparent, and immediately understandable when triggered.
- Statistical models: for what cannot be described with a rule. Expected behavior is reconstructed from historical data, taking seasonality and trends into account, and an anomaly is a significant deviation from that reference.
There is also a third case, where a forecasting model already exists: the anomaly is simply an observed value outside the predicted range.
How we keep the noise down
- Deduplication: the same persistent anomaly does not generate an alert every time the system checks.
- Grouping: related anomalies with a common cause are delivered as a single notification.
- Scheduled suppression: checks are suspended during known interventions or planned shutdowns.
- Feedback: the recipient can mark an alert as irrelevant, and this feedback is incorporated into system tuning.
The percentage of alerts marked as irrelevant is the system's health indicator. Above a certain threshold, the problem is with the tuning, not with the people who do not respond.
From alert to action
An anomaly can trigger a process, not just a notification: block the publication of non-compliant data, open a ticket already populated with the relevant context, suspend a synchronization, or start a verification workflow.
This is the point where monitoring stops being passive and connects to the automation layer. The threshold above which the system acts on its own, and the one above which it asks a person to intervene, are defined process by process.