Why Time Windows Matter (and Why Thresholds Can Mislead)

In industrial systems data is usually available, so that is not a problem, the problem is context.

Every second, machines generate thousands of data points. When something goes wrong, the challenge isn’t detecting that an anomaly occurred it’s understanding why. And that’s where time windows become critical.

Root cause analysis is not about a point in time, it’s about the full sequence of events.

‍

The Problem with Static Snapshots

Traditional analysis often relies on fixed time slices:

• “Look at the last 5 minutes”

• “Check data from 10:00–10:15”

• “Compare hourly averages”

In many cases, these windows are not chosen because they reflect the real behavior of the system but because a hard threshold was crossed at a specific moment.

The moment a signal exceeds a predefined limit, you start analyzing. But that moment is often just a symptom, not the start of the problem.

A machine failure might:

• Start subtly long before a threshold is crossed

• Escalate rapidly in seconds

• Recover slowly over time

If your time window is anchored only to when the alert fired, you risk analyzing a partial and biased slice of the event.

You miss what happened before, and you may ignore what happened after.

If your time window cuts off any part of this sequence, you lose the narrative and with it, the root cause.

What you’re left with is a fixed time slice driven by a threshold.

What you actually need is a time window that reflects the entire anomaly itself.

‍

Anomalies Are Temporal Events, Not Points

An anomaly is not a single timestamp. It is a time-bound event with structure:

1. Onset: when behavior first deviates

2. Escalation: when deviation grows

3. Peak: when the anomaly is most severe

4. Resolution: when the system stabilizes

Each phase carries different information:

• The onset often contains the root cause

• The peak shows the impact

• The resolution reveals system resilience

Miss one, and your analysis becomes incomplete.

The Hidden Cost of Poor Time Windows

1. Mistaking Symptoms for Causes

If you only analyze the peak, you’re often looking at consequences not triggers.

2. Losing Early Warning Signals

Subtle deviations before the anomaly are often the most valuable signals but they’re easy to miss if your window starts too late.

3. Introducing Noise

Expanding the window arbitrarily can dilute the signal with unrelated events, making patterns harder to detect.

4. Breaking Causal Chains

Industrial systems are interconnected. A delay in one subsystem might trigger a failure elsewhere minutes later. Poor windowing breaks these relationships.

A Better Approach: Treat Anomalies as Complete Stories

Effective root cause analysis requires reconstructing the entire lifecycle of an anomaly:

• When did it truly begin?

• What changed leading up to it?

• How did it propagate across the system?

• When did the system actually recover?

Instead of analyzing fixed intervals, the goal is to define dynamic time windows that adapt to the anomaly itself.

Why This Matters Even More Today

Modern systems don’t just generate more data they process it differently.

With high-frequency signals, distributed systems, and real-time pipelines:

• The cost of analyzing large, unfocused time ranges grows quickly

• The signal-to-noise ratio drops as more irrelevant data is included

• Compute resources are often spent processing data that has no causal relevance

Well-defined time windows solve this by:

• Reducing compute overhead (processing only what matters)

• Improving model accuracy (less noise, clearer patterns)

• Enabling faster analysis (smaller, more meaningful datasets)

In other words, better time windows don’t just improve insight they improve efficiency.

As systems scale, this becomes essential. It’s not just about finding the root cause it’s about doing it quickly and reliably.

A Practical Example

Imagine a temperature spike in a production line:

• 10:02: Temperature begins drifting upward

• 10:07: Cooling system efficiency drops

• 10:10: Alert threshold is crossed

• 10:12: Peak temperature reached

• 10:18: System stabilizes

If you only analyze 10:10–10:12, you miss:

• The cooling degradation at 10:07 (likely root cause)

• The early drift at 10:02 (early signal)

The true story spans 10:02–10:18.

The Key Insight

The quality of your root cause analysis is directly tied to how well you define your time window.

Too narrow and you miss the cause
Too wide and you add noise
Well-defined and you uncover truth

Bringing It All Together

The most effective systems don’t rely on arbitrary time slices. They adapt their analysis window to the anomaly itself capturing it from its true beginning to its true end.

This shift from static snapshots to dynamic event-based windows is what turns raw data into real understanding.

Where This Becomes Powerful

This is exactly the approach we take at MontblancAI.

Instead of analyzing fixed intervals, anomalies are isolated as complete time windows from the first deviation to full recovery. This ensures that every contributing signal, system interaction, and causal relationship is captured within a single, coherent view.

Once that window is clearly defined, something even more powerful becomes possible:
you can contextualize the anomaly against external data sources.

Because the anomaly is no longer just a vague point in time, but a precise event, you can now correlate it with:

• Other machines and subsystems

• Environmental conditions (temperature, humidity, etc.)

• Upstream and downstream processes

• Operational data (shifts, operator actions, maintenance events)

This makes it possible to move beyond isolated signal analysis and into true system-level reasoning.

Because when you analyze the full story and connect it to everything happening around it the root cause becomes much easier to see.

‍