Predictive maintenance with n8n: centralizing IoT sensor alerts before failure

In most industrial plants, the data already exists: a PLC measuring vibration, a temperature probe on a motor, an hour counter on a compressor. The problem isn't a lack of sensors — it's that the data is scattered: a SCADA dashboard only the shift technician checks, a manual CSV export once a week, an audible alarm everyone has learned to tune out. The breakdown then arrives without anyone having cross-referenced the signals that announced it in time. n8n doesn't replace an industrial monitoring system, but it excels at exactly what's missing between the sensors and the maintenance team: centralizing the streams, filtering the noise, and routing the right alert to the right person before a production stoppage becomes the only option left.

Why centralize before you predict

"Predictive maintenance" often conjures up a sophisticated machine learning model trained on years of history. In practice, the first — and most cost-effective — win is almost always simpler: bringing together signals that already exist but have never been cross-referenced. A systematic literature review of predictive maintenance in Industry 4.0 by Tiago Zonta and co-authors (Predictive maintenance in the Industry 4.0: A systematic literature review, Computers & Industrial Engineering, 2020, covering 187 studies) finds that IoT integration and the centralization of sensor data form the indispensable foundation of any predictive approach — well before the sophistication of whatever model sits downstream. In other words: a reliable ingestion-and-filtering pipeline pays off faster and more reliably than an isolated predictive model fed by scattered data.

That's exactly the role an automation tool like n8n can play in a predictive maintenance program: not replacing the sensors or the CMMS (computerized maintenance management system), but acting as the connective tissue between the two.

Ingesting sensor data into n8n

Three families of sources cover nearly every case you'll encounter on a shop floor:

• MQTT: the de facto protocol for sensors and PLCs that already publish to a broker (Mosquitto, AWS IoT Core, HiveMQ). n8n's MQTT node subscribes to a topic (for example plant/line3/motor-a/vibration) and triggers a workflow on every new reading, with no extra network configuration on the sensor side.
• Webhooks from a monitoring platform: most modern SCADA or CMMS solutions (Losant, ThingsBoard, Fiix, Hexagon) expose webhooks or a REST API triggered on threshold breach. An n8n Webhook trigger then receives the event already pre-filtered on the platform side.
• Scheduled polling: for an older PLC with neither an API nor MQTT, a Schedule Trigger periodically queries a Modbus-to-HTTP gateway or a local database exposed by the integrator — less reactive, but universal.

In all three cases, the raw data landing in n8n is the same shape: an equipment identifier, a measured value, a timestamp. The real work starts after that.

Filter before you alert: thresholds, hysteresis and deduplication

A vibration sensor oscillating around a threshold generates, without filtering, dozens of identical alerts per hour — the surest way for a maintenance team to end up ignoring the whole channel. Three combinable safeguards:

1. Threshold with hysteresis: trigger above a high threshold, but only allow a new trigger after the value drops back below a distinct low threshold. An IF or Switch node is enough to implement this once both bounds are stored alongside the equipment.
2. Non-repeat window: record, for each piece of equipment, the timestamp of the last alert sent — in an n8n Data Table for lightweight needs, or a Postgres table if the number of sensors is large — and block any new alert until the minimum window (say, 30 minutes) has elapsed.
3. Deduplication by shared root cause: when a single fault makes several sensors react at once (vibration and temperature rising together on the same motor), a Remove Duplicates node or an aggregation keyed on equipment ID groups these signals into one ticket instead of one per sensor.

This filtering step, invisible but decisive, is what separates a usable alert pipeline from a stream of notifications nobody reads anymore.

Letting an AI agent prioritize before a human does

Once the noise is gone, not every remaining alert carries the same urgency: a slow temperature drift on a redundant unit doesn't deserve the same response as an abnormal vibration on the plant's only press. Susto and co-authors, in Machine Learning for Predictive Maintenance: A Multiple Classifiers Approach (IEEE Transactions on Industrial Informatics, 2015), show that multi-criteria classification (signal type, equipment criticality, failure history) meaningfully improves prioritization compared with a single threshold applied uniformly.

In n8n, an AI Agent node can play that triage role without training a dedicated model: given the relevant context (equipment involved, measurement type, value, recent alert history for that equipment pulled from Postgres or a Data Table), the agent classifies severity (informational / to monitor / urgent), drafts an actionable description for the technician, and can consult the equipment's maintenance documentation if it's indexed in a vector store — a direct application of RAG with Supabase to technical documentation instead of customer support.

Routing to the right channel based on severity

An "informational" alert can land in a Slack channel reviewed at the next team huddle. An "urgent" alert on critical equipment deserves a different channel — on-call SMS, an automated call — and, for decisions that involve stopping a production line, explicit human sign-off rather than an automatic action. Combining the Wait node with Slack buttons pauses the workflow until a supervisor confirms the shutdown, while a Stop and Error node explicitly documents the cases where the workflow should halt rather than guess what comes next.

A complete workflow example

1. MQTT trigger on a production line's sensor topics, or a Webhook from the monitoring platform.
2. Enrichment: join with equipment metadata (criticality, history) stored in Postgres or a Data Table.
3. Filtering: threshold with hysteresis, non-repeat window, aggregation by equipment.
4. AI Agent: severity classification and an anomaly description, with access to indexed technical documentation.
5. Conditional routing: Slack for an informational alert, SMS/call for an urgent one, Wait plus human approval before any line stoppage.
6. Logging: the alert, its severity and the decision taken are written to a history table, reusable for maintenance audits.

Keeping an audit trail for regulatory checks

In industrial settings, traceability of maintenance actions isn't a nicety — it often underpins quality audits (ISO 9001, ISO 27001) or sector-specific safety obligations. The principle described in our guide to GDPR audit trails with n8n and Supabase applies directly here: every alert handled, every shutdown decision confirmed by a human, every intervention triggered is worth logging with a timestamp and an execution ID — a solid foundation if your organization ever needs to prove a warning signal was handled within the required timeframe. The Compliance & Audit Pack (€149) provides a starting point for this kind of logging, designed to be adapted to an industrial context rather than a purely software one.

Going further

Predictive maintenance doesn't require starting from a data lake and a deep learning model: it starts with a reliable pipeline that centralizes what your sensors already report, filters the noise, and prioritizes what actually deserves a technician's attention. n8n covers that orchestration layer without needing a dedicated data team — a realistic starting point before, eventually, investing in a finer-grained anomaly detection model once your data history is clean enough to train one.