Every IoT deployment starts with the same anomaly strategy: a threshold. Alert if temperature goes above 8 degrees. It works, it is easy, and it catches the obvious failures. For a while, that feels like enough.
Then reality complicates it. The freezer that reads 7.9 degrees for six hours straight is technically in range but clearly failing. The pump whose vibration is normal for its absolute value but abnormal for a Tuesday morning. The sensor that drifts slowly rather than spiking. Fixed thresholds miss all of these, because an anomaly is not “a big number.” It is a reading the normal pattern would not have predicted.
Detecting that kind of anomaly takes a progression, from thresholds to baselines to AI-assisted investigation. Here is the progression, what each stage catches, and how to build it without boiling the ocean.
Stage 1: Thresholds, and their honest limits
Start here, because you should. A static threshold is cheap, transparent, and correct for hard limits that never change. A vaccine fridge must never exceed 8 degrees, full stop. That is a threshold, and TagoIO Actions handle it directly: define the condition, define the response, done.
The limit is that thresholds only know absolute values. They cannot tell that a reading is fine in isolation but wrong in context. They fire late on slow drifts and stay silent on patterns. So thresholds are the floor of anomaly detection, not the ceiling. Keep them for the hard limits, and add the next stage for everything else.
Stage 2: Statistical baselines
The next step is to compare each reading against what is normal for that sensor, at that time, in that context, rather than against a fixed line. This is where most of the real value sits, and it does not require machine learning to start.
The idea is a rolling baseline. Compute the recent mean and standard deviation for a variable, then flag readings that fall too far outside the expected band, say beyond three standard deviations. That single technique catches spikes a threshold would clear and drifts a threshold would miss, because the band moves with the data. You can build this today with a TagoIO Analysis script that reads recent history, computes the band, and writes an anomaly flag back as a variable your dashboard and Actions can use.
The refinement that matters for IoT is context. Temperature that is normal at 2 a.m. may be abnormal at 2 p.m. A baseline segmented by hour, day of week, or operating mode is far more accurate than one flat average. This is unglamorous statistics, and it outperforms a naive AI model on most sensor streams because it encodes what you actually know about the process.
Stage 3: AI-assisted investigation
Here is the honest framing on AI, because the phrase “AI anomaly detection” is oversold. For the detection step itself, a well-built statistical baseline is often as good as a model and far easier to trust and debug. Where AI earns its place is not usually in flagging the anomaly. It is in explaining it.
A statistical baseline tells you Unit 4 breached at 3:20 a.m. It does not tell you why, or whether it is part of a pattern, or what to do. That investigation, correlating the breach with other variables, checking whether the same unit misbehaved last week, and drafting the fix, is exactly what an AI assistant does well when it can reach your real data.
With the TagoIO MCP server, you can ask an assistant to investigate a flagged anomaly against your actual account: pull the surrounding readings, check the device’s history, and propose a tightened Action. The detection stays statistical and auditable; the AI does the tedious correlation and the first-draft response. We cover that querying workflow in how to query your IoT data in natural language, and the broader picture in what MCP means for IoT.
A practical build order
You do not need all three stages on day one. Build in this order and each stage pays for itself before you add the next.
Start with thresholds on your true hard limits, using Actions. Add a rolling statistical baseline for the variables where context matters, with a simple Analysis script writing an anomaly flag. Segment that baseline by time or mode once you see false positives clustering at predictable hours. Then, once anomalies are being flagged reliably, connect an AI assistant through MCP so investigating them takes a question instead of an afternoon.
The trap to avoid is starting at stage three. An AI investigating anomalies you have not learned to detect reliably is a confident guess on a shaky foundation. Detection first, explanation second.
The takeaway
Anomaly detection is a progression, not a product. Thresholds catch hard-limit failures. Statistical baselines catch the spikes and drifts that thresholds miss, and they are more trustworthy than most people expect. AI is best used to investigate and explain the anomalies your baselines surface, grounded in your real data through MCP. Build in that order and you get a system that is accurate, debuggable, and genuinely useful, rather than an impressive demo that no one trusts in production.
Want to build it? See Analysis and Actions in the docs, or start free on TagoIO and flag your first anomaly this week.
