"Pump B7 tripped Tuesday, and nobody knew until Thursday." That's the dashboard-polling problem, and it's why industrial teams are moving to push-based, natural-language alerting that reaches the right person the moment a threshold breaks.

"Nobody was watching the screen."

That's the line a shift supervisor uses after pump B7 trips and the plant loses four hours of production. It's not that the data wasn't there. The trend was sitting in a dashboard, in a tile, on a screen somebody was supposed to check.

Nobody did. Not because they're careless, but because dashboards are built on an assumption that doesn't hold up in a real plant: that a person will look at the right chart, at the right moment, before the problem gets expensive.

That assumption is the gap between industrial monitoring and industrial real-time alerting. Monitoring collects and displays data. Alerting pushes an answer to a person the instant a threshold breaks, whether or not anyone was looking. Most vendors in this space stop at the first one. Spocky is built for the second.

The dashboard-polling loop, and where it breaks

Here's the loop most plants run today, whether they know it or not:

Sensor captures data. Temperature, pressure, vibration, flow: the raw signal comes in continuously.
Data lands in a historian or dashboard. It's stored, plotted, maybe color-coded.
A person checks the dashboard. On a schedule, or when something else prompts them to look.
If the person notices an anomaly, they investigate. If they don't notice, the anomaly waits.
By the time someone does notice, the condition has often already caused damage: a bearing has already worn, a pump has already tripped, a batch has already gone out of spec.

Step 3 is the failure point. It puts a human polling loop in the middle of a process that runs continuously, 24 hours a day, across dozens or hundreds of assets. No shift has enough eyes for that. Nobody has to be negligent for this to fail; the architecture guarantees it eventually will.

This is the same failure pattern we've written about in the pump trip investigation delay: the data existed the whole time. The gap was never data collection. It was getting the right fact to the right person at the right moment, without a person needing to go looking for it first.

Push-based alerting closes the loop dashboards leave open

Industrial real-time alerting flips the polling loop into a push loop:

A threshold or pattern is defined: a temperature limit, a vibration signature, a rate of change that historically preceded a trip.
The agent watches the raw time-series continuously, not on a refresh cycle tied to when a person opens a browser tab.
The moment the threshold breaks, the agent pushes a plain-language alert to the shop manager, the quality lead, or whoever owns that asset: not a chart that requires interpretation, but a stated condition: what broke, on what asset, compared to what baseline.
The alert is cross-referenced against maintenance logs and history automatically, so the person receiving it isn't starting from zero.
A person still decides what happens next. Spocky doesn't act on the fleet without a decision step. It gets the right person to the decision faster.

The difference isn't cosmetic. A dashboard is a resource someone has to spend attention to consult. An alert is delivered. That's the entire idea behind compute-down, conversational analytics: instead of asking a person to go find the anomaly buried in raw data, the anomaly finds the person.

Why this matters more as fleets get bigger

Dashboard-polling degrades as the number of assets grows. Two people can plausibly watch five dashboards. They cannot watch five hundred.

That's the real test of an alerting approach: does it hold up at fleet scale, or does it quietly assume someone is always watching?

A two-person detection team can supervise a fleet of 400+ heat pumps when the alerting is push-based, because the team isn't scanning screens, they're responding to specific, pushed conditions the moment they cross a threshold. That's a materially different job than dashboard-checking. It's the difference between watching for a problem and being told about one.

Why re-ingesting everything into an LLM isn't the answer either

Some teams try to solve the polling problem by pointing a large language model at their historian and asking it to watch for anomalies. This runs into a hard technical wall fast: one heat pump's raw time-series data for a single week can be 5 to 30 times larger than the biggest context window on the market today. Multiply that across a fleet and it's not a workable architecture; you can't re-ingest your way to real-time.

Spocky's compute-down architecture avoids this by sending the math to the data instead of shipping billions of raw points into a model's context window. The threshold check, the pattern match, the cross-reference against history: all of that runs where the data already lives. Only the answer travels. That's what keeps latency and token use down while still working across raw, full-resolution history instead of a sampled slice of it. For more on why the re-ingestion approach breaks down at scale, see why re-ingesting time-series data into an LLM fails at industrial scale.

Deterministic alerts, not another dashboard to interpret

There's a second, quieter problem with a lot of monitoring tools: even when they do alert, the alert requires interpretation. A flashing tile or a vague threshold breach still leaves the person asking "okay, but what does this mean, and what do I do?"

Spocky's alerts are deterministic and explainable: the same underlying condition produces the same answer every time, and the reasoning behind it is traceable, not a best guess presented with false confidence. That matters most under pressure, when a shift supervisor doesn't have time to second-guess whether the alert is real or noise.

This is a different problem than the one covered in our comparisons of historians versus natural-language query agents or Seeq alternatives: those are about investigation, asking "why did this happen." Alerting is about the moment before the question even gets asked: making sure someone knows something happened at all.

What this looks like end to end

Put the two loops side by side.

Dashboard-polling loop: sensor → historian → dashboard tile → person happens to check → person notices → person investigates → damage may already be done.

Spocky's alerting loop: sensor → compute-down engine watches continuously → threshold breaks → plain-language alert pushed to the right person → alert arrives pre-cross-referenced with history → person makes the call.

The second loop doesn't remove the person. It removes the polling. Nobody has to remember to check anything. The agent is embedded in the loop the team already runs, not a screen bolted onto the side of it.

This connects directly to the truck-roll pain point many service and asset-heavy teams carry: dispatch is reactive when the first sign of trouble is a customer complaint. A connected-assets deployment that pushes alerts instead of waiting for someone to notice a dashboard anomaly saw 75% fewer site visits, because faults were caught and, where possible, resolved remotely before a truck needed to roll. Read more on that pattern in the real cost of a truck roll.

Where alerting fits in the bigger operating loop

Alerting isn't the whole story: it's one stage in a longer loop that starts with exploring raw data and ends with prediction. Spocky's agents are built to move through that loop: explore an anomaly, automate the check that catches it next time, support a supervised action, document what worked, and eventually predict the next occurrence before it happens.

Real-time alerting is the stage that makes the rest of the loop possible. Without a push mechanism, every one of those later stages still depends on someone remembering to look. With it, the loop runs whether or not anyone's watching the screen, and the person who needs to know still gets the call, in seconds, not after the next shift finds out the hard way.

FAQ

What's the difference between industrial monitoring and industrial real-time alerting?

Monitoring collects and displays operational data: it's the dashboard, the chart, the trend line. Alerting pushes a specific, plain-language notification to a person the moment a threshold breaks, without requiring anyone to go check a screen first. Monitoring shows you data exists; alerting makes sure someone finds out about a problem when it happens, not whenever they next look.

Does real-time alerting replace a historian?

No. A historian remains the record of what happened over time. Alerting sits on top of that raw history, watching it continuously and pushing a notification the moment a defined condition is crossed, cross-referenced against past events and maintenance logs automatically.

Does Spocky take action automatically when an alert fires?

No. Spocky pushes the alert and the relevant context to a person: the shop manager, quality lead, or asset owner, who decides what happens next. A human decision step always comes before any action on a fleet.

How is this different from setting up alarms in a SCADA or historian system?

Traditional alarms are often threshold rules tied to a single tag, and they still surface as another item on a dashboard or alarm list someone has to check and interpret. Spocky's alerts are pushed in plain language, cross-referenced with history and maintenance context automatically, and reasoned deterministically so the same condition produces the same explainable answer every time.

Can real-time alerting work across a large fleet without more headcount?

Yes: a two-person team can supervise a fleet of 400+ heat pumps when alerting is push-based, because the team responds to specific pushed conditions instead of scanning dashboards across every asset.

Why Real-Time Alerting Beats Dashboard-Polling for Industrial Ops Teams