A quiet weekend looks normal. A weekday collapse in orders doesn't — but if nobody's watching the numbers, both can slip by unnoticed until someone stumbles on the damage days later. Kademi's new anomaly detectors watch your key metrics automatically, so you find out the same day something goes wrong, not the week after.
This guide covers how detectors decide what's "normal," where to check them, what the states mean, and how to set up a detector of your own.
What counts as "normal"
A metric like order count or web traffic naturally rises and falls with the day of the week — busy Thursdays, quiet Sundays. A detector that ignored this pattern would cry wolf every Monday morning and stay silent through every quiet weekend, which is exactly the kind of alert people learn to ignore.
So each detector compares a period only against the same period in recent history: a Thursday against the last four Thursdays, or 3am on a Sunday against the last four 3am Sundays. That comparison — not a flat average — is what "normal" means here.
For a period to actually get reported as unusual, three things all have to be true at once:
- It's well outside the usual spread for that period
- It's well outside a percentage band (e.g. dramatically higher or lower than typical)
- The change is large enough in absolute terms to matter
Requiring all three is deliberate. Any one of them alone produces false alarms on real data — the minimum-change requirement, in particular, is what stops a quiet account going from one order to three orders in a day from being flagged as a crisis.
One detail worth knowing: the two web-error detectors (4xx and 5xx) only report when errors go up. Fewer errors than usual is good news, not an incident — so they don't watch for a "too few errors" alarm the way order or signup metrics watch in both directions.
Detectors don't need to start from zero, either. They build their baseline from existing data as soon as they're switched on, so they can start reporting anomalies almost immediately — rather than waiting weeks for enough history to accumulate.
Where to find it
Anomaly detectors live under Reporting → Anomaly detectors. You'll need the Reports Viewer or Reports Manager role to see the page.
Reading the list page
At the top, four summary tiles give you the state of play at a glance:
- Detectors — how many exist and are actively recording
- In alarm — how many currently have something abnormal going on
- Building a baseline — how many are still gathering history and haven't started reporting yet
- Not running — how many can't currently run, and why
Below that, the table lists each detector with:
- Metric and Period (daily or hourly, depending on what's being watched)
- Latest reading and the date it was taken
- Of normal — the latest reading as a percentage of what's typical for that period
- Reported — how many times this detector has flagged something as unusual
- Notifications — whether alerting is switched on for this detector
For example, a Bandwidth detector might show a reading that's 79% of normal, or a Client errors detector might show 13,267% of normal — both are just the current reading relative to the baseline. Whether that actually counts as an alarm depends on whether all three trip conditions above were met; a number that looks high or low in the "Of normal" column doesn't necessarily mean an alarm has been raised.
Understanding detector states
Each detector moves through a lifecycle:
- Building a baseline — a fresh detector builds its baseline from existing data as soon as it's switched on, so this stage is usually brief. A detector only stays here if there isn't enough comparable history yet (for example, a very new metric) — and it won't report anomalies until it moves past this stage.
- Normal — recording, with nothing unusual going on.
- In alarm — the detector has seen enough consecutive unusual periods in a row to call it an incident, not noise. It'll stay in this state until it sees enough clean periods afterward to be confident things are back to normal.
- Not running — the detector can't currently be evaluated (for example, if the index query it depends on isn't available). The list page states the reason directly rather than just hiding the row — a monitor that can't tell you whether it's working isn't much of a monitor.
The Reported count is a running tally of how many times this detector has ever flagged an unusual period, going back through its history — a quick sense of whether a metric has a track record of instability or has been rock-solid.
Where else alarms show up
You don't have to remember to check the detectors page. Open alarms also surface in a few other places, so an abnormal metric is more likely to be noticed:
-
Admin dashboard — when at least one detector is in alarm, a "metrics behaving abnormally" summary appears in your dashboard activity feed, with a row per alarm (or a combined row if there are several).
Admin dashboardActivity queue → "Metrics behaving abnormally" -
Reporting dashboards page — alongside your list of dashboards, a "Metric alarms" panel shows an at-a-glance view: which detectors are abnormal right now, and the percentage that's driving it, each linking through to the detector's own page.
Reporting dashboards pageThe "Metric alarms" panel -
Index query pages — if a detector is watching a particular index query, that's noted right on the query's own page, along with whether it's currently in alarm or paused. It's a reminder that editing that query's aggregations changes what the detector is actually measuring.
Noted on the index query pageWeb activity → "Watched by 3 anomaly detectors"
Creating a custom detector
A set of default detectors ships out of the box. Which ones you actually see depends on which apps you have installed — order detectors, for example, come with the Products app, and points detectors come with KPromotions. If you want to watch something else, you can create your own against any index query that has a date histogram.
- From the Anomaly detectors page, select New detector.
- Give it a Name shown to people — this is the label everyone else will see.
- Set an Identifier — a short, unique code (letters, digits, dots, underscores, hyphens only). This becomes part of the detector's page address, so it can't be changed later.
- Choose the Index query to read — the underlying data source the detector will watch.
- Select Create detector.
A new custom detector is created paused, so you can review and tune its sensitivity settings before it starts recording anything. Once you're happy with it, switch it on — it'll build its baseline from the index query's existing data, the same way the default detectors do, so it can generally start reporting anomalies right away rather than waiting weeks.
Why this matters
Most of the time, when something goes wrong quietly — a fraud pattern in points redemptions, a broken integration cutting off signups, an error rate creeping up on a live site — the first sign isn't a crash, it's a number that's quietly drifted from where it should be. Anomaly detectors mean that drift gets flagged automatically, in language you can act on: not just "something changed," but how much, compared to what, and whether it's still ongoing.
Nine detectors are already watching your core metrics with no setup required. If there's something else worth keeping an eye on, setting up a custom detector takes just a few clicks.