DEV Community: ThresholdIQ

The 9 ML Anomaly Detection Methods ThresholdIQ Uses — Explained in Plain English

ThresholdIQ — Tue, 24 Mar 2026 01:53:20 +0000

When you upload a spreadsheet to ThresholdIQ, nine separate machine learning methods run simultaneously across every column in your data. Each one is looking for a different type of problem. Some catch sudden spikes. Others find slow drift. One looks for sensors that have frozen. Another watches for two metrics that normally move together suddenly moving apart.

Most people don't need to know how any of this works — they just want the anomaly flagged. But if you've ever wondered "why did **ThresholdIQ **flag that?" or "what would it miss?", this guide is for you. Each method gets a plain-English explanation, a concrete worked example, and an honest summary of what it catches and what it doesn't.

Contents

Multi-Window Z-Score — the primary severity driver
EWMA Spike Detection — sudden event catcher
SARIMA Seasonal Residuals — seasonality-aware detection
Isolation Forest — multivariate outlier detection
Correlation Deviation — correlated failure detection
DBSCAN Cluster Noise — behavioural outlier detection
Seasonal Baseline — time-of-day / day-of-week context
Trend Detection — gradual drift early warning
Stuck & Zero Detection — sensor failure & line halt How the 9 methods work together: Each method runs independently and produces a score. ThresholdIQ fuses these scores using a weighted formula — multi-window Z-score drives the primary severity, and the other 8 methods can only boost severity, never reduce it. This means a false positive from one method can't override a clean result from the others — but genuine anomalies that multiple methods agree on escalate quickly to Critical or Emergency.

Method 1 of 9

Multi-Window Z-Score

The primary severity driver — compares every data point to multiple time horizons simultaneously
Plain-English explanation
A Z-score answers one question: "How far is this value from normal, measured in standard deviations?" A Z-score of 0 means perfectly average. A Z-score of 3 means three standard deviations above average — unusual for any distribution. Most single-metric alert systems use one Z-score window. **ThresholdIQ **runs four windows in parallel: 50 points (short-term), 100 points (mid-term), 200 points (long-term), and 500 points (very long-term). Each window has its own rolling mean and standard deviation.

Analogy: Imagine four weather forecasters, each looking at a different time period — the last week, the last month, the last quarter, and the last year. If all four agree that today's temperature is unusually high, you can be very confident it really is abnormal. If only the "last week" forecaster flags it, it might just be a warm spell. Multi-window Z-score works the same way: agreement across windows = high confidence = higher severity.
How severity is determined
The number of windows simultaneously breached maps directly to severity level:

W50 breach only → Warning
W50 + W100 both breached → Critical
W50 + W100 + W200 all breached → Emergency Worked example — daily cash flow monitoring Example data: Finance team daily cash inflow (A$000s) Day Cash inflow W50 Z-score W100 Z-score W200 Z-score

Result

Mon $142k 0.3 0.2 0.1 Normal
Tue $138k -0.1 -0.2 -0.1 Normal
Wed $41k 3.4 1.8 1.2 ⚠️ Warning (W50 only)
Thu $38k 3.8 3.1 1.9 🟠 Critical (W50+W100)
Fri $29k 4.2 3.7 3.2 🔴 Emergency (all 3)

Wednesday's drop fires a Warning — unusual in the short term but not yet confirmed. By Friday, all three windows agree the cash inflow is far below normal. The anomaly has persisted and escalated to Emergency. This is a structural problem, not a one-day blip.

Catches

Sudden large spikes or drops
Sustained deviations that persist over time
Values that are unusual at any time horizon
Escalating anomalies (gets worse each period)
Misses on its own
Seasonal patterns (Sunday lows look anomalous)
Gradual drift that's slow enough to shift the mean
Multi-metric relationships between columns

Method 2 of 9

EWMA Spike Detection

Exponentially Weighted Moving Average — catches sudden instantaneous events that resolve quickly

Plain-English explanation

EWMA (Exponentially Weighted Moving Average) is a special kind of average that gives more weight to recent data and less weight to older data. It creates a smoothed trend line through your data. Anything that deviates sharply from that smooth line — a sudden spike or crash — gets flagged.

Think of it as the difference between the trend and the actual value. EWMA subtracts the smoothed trend from each actual reading. What's left (the residual) tells you what's unexpected. When the residual exceeds 3 standard deviations, EWMA fires.

Analogy: You drive to work every day and the journey takes about 35 minutes. EWMA is like tracking your rolling average journey time, weighted towards recent trips. One day you hit an accident and it takes 90 minutes. The EWMA trend says "expected: 36 mins" — the actual is 90 mins — the residual is massive. Flag. Next day it's back to 34 minutes. The spike resolved quickly, but EWMA caught it the moment it happened.
Worked example — e-commerce daily revenue
Example data: Online store daily revenue (A$)
Date Actual revenue EWMA trend Residual Result
Mar 18 $14,200 $13,980 +$220 Normal
Mar 19 $13,900 $13,960 -$60 Normal
Mar 20 $2,100 $13,850 -$11,750 🔴 Emergency spike
Mar 21 $13,600 $13,740 -$140 Normal (resolved)
EWMA catches the Mar 20 revenue collapse on the same day it happens — before it shows up in any weekly report. It also correctly shows the next day as normal, so you don't get ongoing false alerts once the issue resolves. This was likely a payment gateway outage or checkout failure.
Catches
Sudden single-period spikes or crashes
Events that resolve quickly (transient anomalies)
Instantaneous sensor readings far from trend
Fast-reacting — fires within the same reporting period
Misses on its own
Gradual drift (the trend line adapts to drift)
Sustained long-term deviations
Patterns that emerge across multiple metrics

Method 3 of 9

SARIMA Seasonal Residuals

Seasonal AutoRegressive Integrated Moving Average — separates predictable patterns from real anomalies
Plain-English explanation
SARIMA is a statistical forecasting model that understands seasonality — predictable patterns that repeat at regular intervals. It learns from your historical data: "Electricity usage is always high on Monday mornings. Revenue always dips on Sundays. Production throughput is always lower on night shifts." It builds a model of what your data should look like at any given time based on those patterns.

Once SARIMA has learned the seasonal model, it computes what it expected at each point, and compares that to what actually happened. The difference (the residual) is what gets analysed for anomalies. A Sunday revenue figure that looks low by absolute standards might be perfectly normal for a Sunday — SARIMA knows this and won't flag it.

Analogy: A supermarket expects long checkout queues on Saturday afternoons — that's just how Saturdays work. SARIMA is the manager who knows all the normal busy and quiet patterns. If queues are long on a Wednesday at 11am (when it's normally quiet), SARIMA flags it. But it never flags Saturday afternoon queues as anomalous, because those are expected.
Worked example — utility gas consumption
Example data: Residential gas consumption (GJ/day)
Date Day Actual GJ SARIMA expected Residual Result
Jun 1 Mon 42.1 41.8 +0.3 Normal
Jun 7 Sun 31.4 32.1 -0.7 Normal (Sundays are always lower)
Jun 8 Mon 44.2 42.0 +2.2 Normal (slight winter increase)
Jun 9 Tue 29.3 41.9 -12.6 ⚠️ Warning (unexpected low)
Without SARIMA, Sunday's 31.4 GJ might look anomalously low compared to weekday averages of ~43 GJ. SARIMA knows Sundays are always lower and ignores it. But Tuesday's 29.3 GJ is far below the Tuesday expectation of 41.9 GJ — that's a real anomaly (possible meter fault or pipeline pressure issue).
Catches
Anomalies that break seasonal patterns
Events that look normal in absolute terms but are wrong for the time period
Day-of-week and hour-of-day deviations
Misses on its own
Anomalies that follow the seasonal pattern (a "seasonal" anomaly)
Very short data histories (needs at least 2 full seasonal cycles)
Multi-metric relationships

Method 4 of 9

Isolation Forest

Unsupervised ML model — detects globally unusual combinations across all metrics simultaneously
Plain-English explanation
Isolation Forest is an unsupervised machine learning algorithm that works by trying to isolate each data point from the rest of the dataset using random cuts. Normal points — those that cluster with similar points — require many cuts to isolate because there are lots of similar points nearby. Anomalous points — those that are unusual — can be isolated in very few cuts because they're far from everything else.

Crucially, Isolation Forest looks at all your columns simultaneously. A reading might be within normal range on any single metric, but if the combination of values is unusual across three or four metrics together, Isolation Forest finds it. This is the key method for catching multi-metric anomalies that single-column monitoring would never detect.

Analogy: Imagine a crowd of 1,000 people, and you're trying to find the one person who doesn't belong. You start drawing random lines through the crowd — "everyone on the left of this line, everyone on the right." A normal person surrounded by similar people takes many cuts before they're alone. An oddly-dressed person standing away from the crowd gets isolated in just two or three cuts. Isolation Forest does this mathematically with your data columns.
Worked example — manufacturing OEE with multiple metrics
Example data: Production line metrics (each column looks normal individually)
Shift OEE % Temp °C Cycle time (s) Reject % Isolation score Result
Day 1 87 68 42 1.2 0.42 Normal
Day 2 86 69 43 1.4 0.40 Normal
Day 3 83 74 47 2.1 0.71 ⚠️ Warning (unusual combo)
Day 4 81 79 52 3.8 0.89 🔴 Emergency (globally isolated)
Day 3's OEE of 83 looks only slightly below normal. Temperature of 74°C is within the accepted range. Cycle time of 47s is a little high. Reject rate of 2.1% might pass inspection individually. But the combination of all four metrics shifting together in the same direction is globally unusual — Isolation Forest catches this as a Warning on Day 3, before any single metric triggers an individual alert. By Day 4 it's an Emergency.
Catches
Multi-metric combinations that are globally unusual
Anomalies that don't breach any individual threshold
Patterns invisible to single-column analysis
Misses on its own
Anomalies in a single column where other columns are normal
Seasonal patterns (doesn't account for time)
Requires enough data to establish "normal" clusters

Method 5 of 9

Correlation Deviation

Monitors whether metrics that normally move together have started moving apart — or diverge when they shouldn't
Plain-English explanation
Some metrics in your data are naturally correlated — they tend to move up and down together. Revenue and units sold. Power consumption and production output. Delivery volume and fuel cost. Correlation Deviation monitors these relationships over time. When two metrics that have historically moved together suddenly diverge — or when two metrics that normally move independently start moving in lockstep — that's flagged as an anomaly.

This method is particularly powerful for catching process failures that don't show up in any single column. If your OEE stays flat but your reject rate climbs, something has changed in the relationship between those metrics — even if neither column individually looks alarming.

Analogy: You track both your heart rate and your step count while exercising. Normally, they move together — more steps = higher heart rate. One day your step count is normal but your heart rate is unusually high. The relationship has broken. Something might be wrong — you might be getting ill, or there's something else stressing your body. Correlation Deviation detects exactly this type of "the relationship broke" signal.
Worked example — operations supplier monitoring
Example data: Supplier B over 4 weeks (metrics normally correlated)
Week Order volume On-time % Historical corr. Deviation Result
Week 1 240 units 96% Strong positive None Normal
Week 2 255 units 94% Strong positive Slight Normal
Week 3 270 units 87% Breaking down Moderate ⚠️ Warning — volume up, OTD dropping
Week 4 290 units 74% Inverted Large 🟠 Critical — relationship fully inverted
Historically, higher order volume correlates with better supplier performance (volume customer = priority service). Now volume is rising but on-time delivery is falling — the relationship has inverted. This is an early signal that the supplier is over-committed and struggling. Neither metric individually would have triggered an alert. The relationship breaking is the signal.
Catches
Correlated metrics that diverge unexpectedly
Process changes that affect metric relationships
Multi-metric failures invisible to single-column rules
Misses on its own
Single-metric anomalies where all correlations hold
Very weak or noisy correlations in the data
Newly added columns with no correlation history

**Method 6 of 9

DBSCAN Cluster Noise

Density-Based Spatial Clustering — identifies points that don't belong to any normal behavioural cluster
Plain-English explanation
DBSCAN (Density-Based Spatial Clustering of Applications with Noise) groups your data into clusters based on density — regions where data points are close together. Points that belong to a dense cluster are normal. Points that sit far from any cluster, in low-density regions of the data space, are labelled "noise" — and those noise points are anomalies.

Unlike methods that flag values outside a threshold, DBSCAN doesn't need to know in advance what "normal" looks like. It discovers the natural clusters in your data and then identifies what doesn't fit. This makes it excellent at catching systematic patterns that are unusual — like a specific product SKU that consistently returns at a different rate from all similar products, or a meter that always reads in a pattern no other meter produces.

Analogy: Imagine dropping 1,000 coloured dots on a map representing where people park their cars. Most dots cluster around shopping centres, stations, and offices. A few dots appear in random fields with no nearby cluster — those are the anomalies. DBSCAN finds those isolated dots without anyone telling it where the normal clusters should be.
Worked example — e-commerce returns by product
Example data: Product return rates and average review score across 8 SKUs
SKU Return rate % Avg review Cluster Result
SKU-001 3.2 4.3 Normal cluster A Normal
SKU-002 4.1 4.1 Normal cluster A Normal
SKU-003 3.8 4.4 Normal cluster A Normal
SKU-004 2.9 4.6 Normal cluster B Normal
SKU-005 3.1 4.5 Normal cluster B Normal
SKU-006 18.7 2.1 No cluster (noise) 🔴 Emergency — isolated outlier
SKU-006 sits completely outside both normal clusters — it has a return rate and review score combination that no other product in the catalogue produces. DBSCAN labels it as noise (an anomaly). This flags a quality issue: the product is defective, mislabelled, or fundamentally not meeting customer expectations. A threshold rule watching return rate alone might catch this eventually, but DBSCAN catches the combined pattern immediately.
Catches
Entities (SKUs, meters, suppliers) unlike any normal group
Systematic defect patterns in quality data
Reverse-wiring and meter tampering patterns
No prior knowledge of "normal" required
Misses on its own
Time-series anomalies (DBSCAN ignores time order)
Anomalies that cluster with other anomalies
Sparse datasets with too few points per cluster

Method 7 of 9

Seasonal Baseline

Maintains separate normal ranges per hour-of-day and day-of-week — context-aware thresholds without manual configuration
Plain-English explanation
The Seasonal Baseline method builds a separate statistical profile for each time bucket in your data. For hourly data, it calculates a normal mean and standard deviation for each hour of the day and each day of the week independently — so "normal for 3am on a Sunday" and "normal for 3pm on a Tuesday" are tracked separately.

This is simpler than SARIMA (it doesn't build a full forecasting model) but it's very effective at eliminating false positives caused by predictable time-based patterns. Night-shift throughput, weekend call volumes, Monday morning order surges — all of these are learned as patterns specific to their time bucket and excluded from anomaly detection.

Analogy: A restaurant manager knows that 20 customers at 1pm on a Tuesday is completely normal, but 20 customers at 1pm on a Saturday is concerningly quiet. They don't need a formula — they just know from experience what each day and time looks like. The Seasonal Baseline does this automatically for every column in your data, learning the expected level for every hour and day combination.
Worked example — call centre ticket volume
Example data: Customer support tickets per hour (operations team)
Time Day Tickets Baseline for this slot Deviation Result
09:00 Monday 47 Mon 9am avg: 44 (±8) +3 Normal
09:00 Sunday 12 Sun 9am avg: 14 (±4) -2 Normal (Sundays are always quiet)
14:00 Wednesday 89 Wed 2pm avg: 38 (±9) +51 (>5σ) ⚠️ Warning — far above Wed 2pm normal
Without Seasonal Baseline, Sunday's 12 tickets might look anomalously low versus the overall weekly average of ~42 tickets/hour. The Seasonal Baseline knows Sunday at 9am averages 14 and treats 12 as normal. Wednesday at 2pm averaging 38 tickets suddenly receiving 89 is genuinely anomalous — something caused an unusual spike on a normally quiet Wednesday afternoon.
Catches
Values that are wrong for the time period even if typical overall
Anomalies on predictably quiet periods (weekends, nights)
Shift-specific deviations in manufacturing data
Misses on its own
Multi-week seasonal patterns (uses fixed day/hour buckets)
Long-term trends (the baseline adapts slowly to drift)
Multi-metric patterns

Method 8 of 9

Trend Detection

Identifies monotonic drift across consecutive rolling windows — the early warning system for gradual degradation
Plain-English explanation
Trend Detection compares the mean value across consecutive rolling windows of 50 data points each. If the mean is consistently moving in one direction — each window's average is higher (or lower) than the previous window's average, across three or more consecutive windows — a trend is flagged. This is monotonic drift: not a spike, not a step change, but a steady, persistent movement in one direction.

This is the method that gives you weeks of advance warning on bearing wear, budget overruns that build slowly, and supplier performance that's eroding imperceptibly. No single period looks alarming. The direction across periods is the signal.

Analogy: Your bathroom scale shows your weight each morning. No single day looks dramatically different. But Trend Detection is the method that notices "you were 78.2kg three weeks ago, then 78.8kg, then 79.3kg, then 79.9kg this week." Each individual reading looks fine. The four-week upward trajectory is the alert. This is how gradual health problems — and gradual data problems — are caught before they become crises.
Worked example — equipment spindle temperature drift
Example data: CNC machine spindle temperature across 4 weekly windows (50 readings each)
Window Period Window mean temp Change from prev. Trend status
W1 Week 1 67.2°C — Baseline
W2 Week 2 68.4°C +1.2°C Monitoring
W3 Week 3 69.9°C +1.5°C ⚠️ Warning — 3rd consecutive rise
W4 Week 4 71.8°C +1.9°C 🟠 Critical — accelerating upward trend
No individual reading breached the "normal operating temperature" threshold of 75°C. A single-threshold rule would have seen nothing. Trend Detection flagged the Warning in Week 3 because three consecutive windows all showed higher averages than the previous — monotonic upward drift. The maintenance team scheduled a bearing inspection, found wear, and replaced the bearing before it caused an unplanned line stoppage. This is what preventive detection looks like.
Catches
Gradual drift that never triggers a single-point threshold
Slowly accumulating budget or cost overruns
Equipment wear and sensor calibration drift
Performance erosion in supplier or sales data
Misses on its own
Sudden spikes (EWMA handles those)
Oscillating or reversing trends
Multi-metric anomalies

Method 9 of 9

Stuck & Zero Detection

Identifies sensor freeze (repeated identical values) and sudden drop to zero — fires Emergency immediately
Plain-English explanation
This is the most straightforward of the nine methods, but it catches some of the most expensive failures. It monitors for two specific patterns:

Stuck values: The same number appearing repeatedly across a rolling window. A live sensor that outputs 47.3 for 20 consecutive readings isn't measuring anything — it's frozen. This indicates sensor failure, PLC communication loss, or a data pipeline that's stuck replaying stale data.
Zero values: A metric that has been producing non-zero readings suddenly drops to exactly zero. This indicates a complete equipment stoppage, a service disconnection, a tracking pixel going offline, or a meter that has stopped registering.
Both patterns immediately escalate to Emergency severity — not Warning, not Critical. They indicate that your monitoring data is no longer trustworthy, which is worse than a bad reading. You can act on an anomalous reading. You can't act on data that secretly stopped updating.

Analogy: Imagine a speedometer in a car that suddenly locks at 60 km/h even while the car decelerates to a stop. A stuck speedometer is worse than an inaccurate one — it's actively lying. You'd rather know you have no speed data than trust a frozen reading. Stuck detection is your warning that the instrument has locked up. Zero detection is your warning that the engine has stopped entirely.
Worked example — production line sensor monitoring
Example 1: Stuck sensor — hydraulic pressure readings (bar)
Reading # Pressure (bar) Status
R-001 142.3 Normal
R-002 141.8 Normal
R-003 143.1 Normal
R-004 to R-024 143.1 (repeated 21×) 🔴 Emergency — sensor frozen
Example 2: Zero drop — e-commerce checkout completions per hour
Hour Completions Status
14:00 47 Normal
15:00 52 Normal
16:00 0 🔴 Emergency — checkout dead
17:00 0 🔴 Emergency — ongoing
Both patterns fire Emergency immediately. There's no Warning-then-Critical escalation because there's nothing to investigate — the data source has either stopped or frozen. In the checkout example, the business lost A$2,200/hour (52 completions × ~A$42 AOV) for two hours before the IT team was notified via the email alert. Without Stuck & Zero detection, this would have only been caught in the next morning's daily sales review.
Catches
Sensor freeze and PLC communication failure
Complete equipment or line stoppages
Data pipeline failures serving stale data
Tracking pixel and analytics disconnections
Meter communication failures in utility data
Misses on its own
Partial failures (low values, not zero)
Sensors that output random noise instead of zero
Legitimate zero readings (planned shutdowns)
How all 9 methods combine into a single severity grade
Running nine separate detection methods is only useful if their results are combined intelligently. **ThresholdIQ **uses a score fusion formula that treats Multi-Window Z-Score as the primary driver, with the other eight methods acting as boosters:

/* Score fusion formula */
final_score = multiWindow_score + min(0.25, ml_composite × 0.25)

/* ML composite weights */
ml_composite =
EWMA(0.12) + SARIMA(0.22) + IForest(0.20) +
Correlation(0.12) + DBSCAN(0.06) +
Seasonal(0.12) + Trend(0.10) + Stuck(0.06)
The key design principle: ML methods can only boost severity, never reduce it. If Multi-Window Z-Score says Warning, the combined ML composite can escalate it to Critical or Emergency, but it cannot declare it Normal. This prevents false negatives — genuine anomalies can't be overridden by other methods — while also preventing false positives from any single ML method firing alone.

Example of fusion in action: A meter reading fires a Warning from Multi-Window Z-Score (W50 breach). SARIMA flags it as unexpected for the time of day (+0.22 boost). Isolation Forest confirms it's a globally unusual reading (+0.20 boost). The combined ml_composite pushes the final score above the Critical threshold. The Warning automatically escalates to Critical — with the signals tab showing exactly which methods fired and why.

Why nine methods and not just one?

Every single one of these methods has failure modes when used alone. Z-Score fires false positives on seasonal data. SARIMA can't catch sudden spikes on new datasets. Isolation Forest doesn't understand time. EWMA can't detect gradual drift. No single method finds everything — but nine methods running in parallel, with intelligent fusion, catches the anomalies that cost real money.

The table below shows which method catches which type of anomaly:

Anomaly type Best method(s)
Sudden single-period spike or crash EWMA, Multi-Window Z-Score
Sustained deviation over many periods Multi-Window Z-Score, Trend detection
Seasonally unexpected value SARIMA, Seasonal Baseline
Multi-metric combination anomaly Isolation Forest, Correlation Deviation
Gradual drift over weeks Trend Detection
Behavioural cluster outlier DBSCAN
Sensor freeze / line halt Stuck & Zero Detection
Any of the above, with time context Seasonal Baseline + all others

Try all 9 methods free — upload your spreadsheet → thresholdiq.app

How ThresholdIQ Detects Anomalies Automatically (No Setup Required)

ThresholdIQ — Tue, 17 Mar 2026 03:45:12 +0000

Most monitoring tools ask you to do the hard work first: decide which columns to watch, pick your thresholds, and configure your rules. But here's the problem — if you already knew exactly what was wrong and where to look, you wouldn't need a monitoring tool.

ThresholdIQ takes the opposite approach. Upload your file. Click detect. The engine figures out what's unusual. This post explains exactly how that works, in plain English.

The Problem With Manual Thresholds
Imagine you're a Finance Analyst monitoring daily revenue. You set a rule: "alert me if revenue drops below £50,000." Sensible. But:

Revenue is always lower on Sundays — does that count?
Revenue has been gradually declining for six weeks — should you have noticed sooner?
Revenue and margin both dropped at exactly the same time today — is that more serious?
A static threshold catches the obvious cases. It misses the subtle, the seasonal, and the correlated ones. ThresholdIQ's automatic engine is designed to catch all of them.

What Happens When You Click "Detect Anomalies"
When you upload a file and click the button, nine detection methods run simultaneously across every numeric column in your data. Here's what each one does and what it catches:

Method What it does What it catches Severity
Multi-Window Z-score Computes local mean and standard deviation over 50, 100, 200 and 500-point rolling windows. Flags values that deviate more than 2–3.5 standard deviations from recent history. Sudden spikes, abrupt drops, sustained departures from normal range Warning → Emergency
EWMA Applies exponential weighting so recent values count more than older ones. Flags residuals between the raw value and the smoothed trend. Fast, sharp spikes that would be missed by a slow rolling average Boosts score
SARIMA Seasonal ARIMA model learns the regular cycle in your data (e.g. daily/weekly patterns). Flags points that deviate from seasonal expectation, not just raw magnitude. Anomalies that look normal in isolation but are wrong for that time of day or day of week Boosts score
Isolation Forest Treats every row as a point in multi-dimensional space (one dimension per metric). Identifies points that are isolated — far from all other points — across all metrics at once. Global outliers, sensor failures, zero readings when value should be non-zero Emergency
Correlation Deviation Monitors whether correlated metrics deviate together in the same direction. Two or more metrics all abnormal simultaneously is a stronger signal than one alone. Multi-metric failures — e.g. revenue AND margin AND volume all drop together Emergency
DBSCAN Groups your data points into "normal behaviour clusters." Points that don't belong to any cluster are labelled noise and flagged. Behavioural outliers — patterns that don't match any known operating mode Critical
Seasonal Baseline Builds a separate mean and standard deviation for every hour-of-day and day-of-week bucket. Sunday overnight readings are compared against Sunday overnight history — not all-time history. Prevents false alarms from normal seasonal lows; surfaces genuine anomalies within their time context Warning
Trend Detection Compares the average of three consecutive 50-point windows. A monotonic rising or falling drift across all three windows is flagged. Gradual budget drift, slow inventory decline, creeping latency — things that look fine today but signal a problem forming Critical
Stuck/Zero Detection Detects when a series that previously had variation becomes constant, or drops to zero from a meaningful non-zero history. Sensor failures, data pipeline outages, broken integrations that produce zeroes instead of real values Emergency
How the Results Are Combined
Each method produces a score between 0 and 1 for every data point. These scores are combined using a weighted fusion formula:

Final score = Multi-Window score + min(0.25, ML composite × 0.25)

The Multi-Window Z-score is the primary driver of severity. The other eight methods can only boost a score — they can never reduce it. This prevents a single false-positive method from masking a real anomaly.
The final score maps to a severity level:

Warning (0.60–0.79): W50 window breached — short-term deviation, may self-resolve
Critical (0.80–0.89): W50 + W100 both breached — confirmed anomaly, investigate
Emergency (0.90+): W50 + W100 + W200 all breached — structural shift, escalate immediately
A Real Example: IoT Sensor Data
Suppose you upload a CSV of hourly temperature readings from three factory facilities over 10 days. Here's what happens:

1
Schema detection: ThresholdIQ finds the timestamp column, the three numeric temperature columns, and the facility dimension. No mapping required.
2
Seasonal baseline: The engine notices temperature is reliably lower overnight (hours 22–06). It builds a separate baseline for each hour slot.
3
Multi-window scoring: A spike at 03:00 Tuesday gets a high W50 score. But the seasonal baseline confirms this is within normal overnight range — so the SARIMA method returns a low residual. Final score stays at Warning.
4
Stuck detection: Facility-C's temperature reads exactly 21.4°C for 20 consecutive hours on Thursday. Stuck detection fires — score jumps to Emergency. This is a sensor failure, not a real reading.
5
Results: The timeline shows Facility-C flagged in red from Thursday 08:00. The Detection Signals tab shows "Stuck/Zero: 1" — exactly one method fired, and it fired confidently.
How Much Data Do You Need?
Data minimums:
Under 10 rows: Detection is blocked — not enough data to learn any baseline
10–49 rows: Basic mode only — Multi-Window and EWMA run. No SARIMA or clustering.
50–99 rows: Reduced mode — SARIMA skipped (needs 40+ points to train). All other methods active.
100+ rows: Full detection — all 9 methods active
For most Finance or Operations exports — weekly KPI reports, monthly actuals, daily ops logs — you'll have well over 100 rows and the full engine runs immediately.

What About False Positives?
This is the most common concern with automated detection. ThresholdIQ addresses it in three ways:

Seasonal awareness: SARIMA and the hourly/daily seasonal baseline prevent routine low periods from triggering alerts.
Multi-window confirmation: A Warning only becomes Critical when it persists into the 100-point window. Transient spikes stay at Warning level.
Fusion capping: ML methods can add at most 0.25 to the base score. A single method can't manufacture a Critical alert on its own.
What You See in the App
After detection completes, ThresholdIQ gives you four views:

Timeline: Your data plotted over time with Warning/Critical/Emergency colour bands and anomaly markers
Distribution: Severity breakdown by metric and dimension group
Alert Log: Every anomaly with its score, reason, and the exact data point value
Detection Signals: Which of the 9 methods fired, how many times, and at what severity — so you understand what the engine saw.

ThresholdIQ-We Rebuilt ThresholdIQ From the Ground Up — Here's What Changed

ThresholdIQ — Sun, 15 Mar 2026 22:57:26 +0000

ThresholdIQ Adaptive Detection Engine

Few weeks ago, I shipped ThresholdIQ with a simple premise: monitor your spreadsheet data without needing a BI tool. You uploaded a file, set some threshold rules, and got email alerts when values crossed them.

It worked. But users kept hitting the same wall: setting thresholds is harder than it sounds. What's the "right" threshold for revenue when your business has seasonality? What about a metric that's been quietly drifting for three months?

So we scrapped the rule-based approach entirely. ThresholdIQ v2 uses 9 concurrent ML detection methods to find anomalies automatically — no thresholds to configure, no false positives from stale rules.

What the engine actually does
When you press Detect, the engine runs per group, per metric, per row — all inside your browser. Nine methods run in parallel:

Multi-Window Z-score builds rolling baselines at four window sizes simultaneously. EWMA catches sudden deviations from exponential trends. SARIMA handles weekly and monthly seasonal patterns. Isolation Forest finds global outliers that local windows miss. Correlation deviation checks whether related metrics moved together. DBSCAN labels isolated noise points. The remaining three catch seasonal day/hour patterns, slow trend drift, and stuck or zero-value anomalies.

Each method contributes a weighted score. The final severity — Warning, Critical, or Emergency — is determined by how many window tiers breach simultaneously. More windows breaching means a more persistent, significant anomaly.

The window control actually works now
The sidebar has always had a 50 / 100 / 200 / 500 pts window selector. In v1 it only changed the chart viewport. In v2, it scales all four detection window sizes proportionally. Choose 50 pts and the engine uses windows of [25, 50, 100, 250] — reactive, catches fast spikes. Choose 500 pts and it uses [250, 500, 1000, 2500] — stable, only flags sustained anomalies. Same data, meaningfully different detection.

The alert log shows real numbers now
One piece of feedback we kept getting: "the Threshold column shows 7,484 for a metric that's measured in percentages." That was because the threshold was inherited from the primary metric's rolling stats, not computed per-metric.

Now every alert row shows the threshold and deviation for that specific metric — in that metric's own units. Revenue deviation shows in dollars. Profit margin shows in percentage points. A new Z-Score column sits alongside Deviation so you get both the raw difference and the statistical significance.

Why browser-side matters
Every calculation — all 9 ML methods, all rolling windows, all group splits — runs entirely in your browser. Your data never hits a server. For finance and operations teams handling sensitive spreadsheets, this isn't a nice-to-have. It's the whole point.

The ML libraries (Isolation Forest, simple-statistics) are now bundled locally. No CDN dependencies that can break, no MIME type errors, no third-party calls.

What's next
We're focused on getting the first real external paying customer before we expand the roadmap. If you're a Finance Analyst, FP&A manager, or Operations lead who monitors spreadsheet data regularly — ThresholdIQ is built specifically for your workflow.

Try it free for 7 days at thresholdiq.app — no credit card, no setup, zero configuration.

ThresholdIQ #AnomalyDetection #ExcelMonitoring #FinanceOps #MachineLearning #SaaS #ProductUpdate

How to Monitor Excel or CSV Files Automatically with Alerts

ThresholdIQ — Mon, 09 Mar 2026 23:15:19 +0000

Power BI is excellent for complex dashboards — but if you just need threshold alerts on Excel data, you don't need that complexity.

I've spent years as a senior data analyst watching small and mid-size teams spend $1,200+ per year on BI tools — just to monitor a handful of KPIs in Excel.

The truth? Most teams don't need dashboards.

They need alerts.

"Tell me when inventory drops below 500 units."
"Warn me when the daily refund rate exceeds 3%."
"Flag any customer with an overdue balance over $10k."

That's it. Simple threshold monitoring. And Excel can't do it automatically.

So I built *ThresholdIQ *— a browser-based Excel alert dashboard that takes 60 seconds to set up.

✅ Upload any structured file (Excel, CSV, JSON, XML)
✅ Set 3-tier thresholds (Warning / Critical / Emergency)
✅ See timeline charts, distribution analysis, alert logs
✅ Export reports as PDF or CSV
✅ Zero data upload — everything runs locally in your browser

Built by a data analyst. Priced for teams, not enterprises. Starts free.

👉 ThresholdIQ

excel #automation #webdev #producitivty