How Factro Catches Machine Trouble Before It Becomes Downtime

A machine rarely fails without warning. It usually runs a little rougher, a little hotter, a little less steady for days before it actually stops — but “a little” is exactly the kind of change a fixed threshold alarm is built to ignore. By the time a reading crosses a hard limit, the machine has often already been degrading for a while, and the failure lands as a surprise anyway.

Threshold alerts only catch problems big enough to cross a line someone drew in advance. A bearing that’s wearing down doesn’t jump straight past that line — it drifts toward it, slowly, in a way a single fixed number can’t see.

Factro’s predictive maintenance runs a second layer underneath threshold checks: statistical anomaly detection on vibration, thermal, and current readings, based on a z-score — how many standard deviations a fresh reading sits from that specific machine’s own recent normal. A CNC spindle that’s always run a bit warm doesn’t get flagged for running warm; it gets flagged when it starts running warmer than it usually does, however subtle that shift is against a shared, one-size-fits-all threshold.

That per-machine baseline is the part that actually matters. Two identical machines on the same line can have genuinely different “normal” vibration signatures depending on how they’re mounted, how old they are, or what they’re currently machining — a shared threshold either misses real drift on one machine or false-alarms constantly on the other. Scoring each machine against its own recent history sidesteps both failure modes at once.

This runs as one of three rule layers in Factro’s predictive maintenance engine — threshold rules on shift-log entries, pattern rules on component health/MTBF history, and this statistical layer on live sensor readings — evaluated automatically every six hours, with an on-demand re-run available any time a supervisor wants a fresh read. Feeding it is the same telemetry pipeline that already ingests sensor data over MQTT or a direct HTTP batch endpoint, so there’s no separate tool to stand up and no second dashboard to check — an anomaly shows up as a maintenance alert next to every other alert a factory already watches.

None of this replaces a maintenance team’s judgment — it’s a way of noticing the quiet drift a person checking gauges once a shift would reasonably miss, and putting it in front of someone before it becomes an unplanned stop.

If you’re running CNC, textile, or other equipment with sensors already reporting vibration, thermal, or current data, this layer runs automatically once that telemetry is flowing — no separate model to train per machine.