The shop floor learns about a failure when the line has already stopped, a defective batch has moved on to packaging, and the supervisor is walking the floor and calling on the radio. Minutes or hours pass between the deviation and the responsible person's response, and every one of them costs money. n8n, an open-source automation platform with self-hosted deployment, closes that gap: it collects events from MES, 1C, and sensors into a single stream and automatically sends notifications about failures and deviations to the right people and systems.
Below is a breakdown of what is actually built on n8n in a production environment. This is not a KT.Team case study, but a review of public templates and n8n community materials with source links.
What is built in n8n: ready-made templates
The n8n template library includes the workflow "IoT sensor monitoring with GPT-4o anomaly detection, MQTT & multi-channel alerts". Its logic is publicly broken down (n8n.io):
- two event sources - MQTT Trigger (sensors publish data to the broker) and Schedule (batch polling) - merge into a single pipeline;
- readings are normalized (temperature, humidity, pressure, CO2) and are deduplicated by SHA256 hash, so the same reading does not trigger alerts again;
- The check node compares values against thresholds (in the template: temperature -10...50 C, humidity 20...90%, CO2 400...2000 ppm) and assigns a level: `critical`, `warning`, or `normal`;
- node Switch (Route by Severity) routes: `critical` goes to Gmail and the `#iot-critical` Slack channel at the same time, `warning` goes only to Slack `#iot-alerts`, `normal` does not generate notifications;
- all readings are written to Google Sheets as a historical store.
The second core template is "Remote IoT sensor monitoring via MQTT and InfluxDB" (n8n.io). Here the MQTT Trigger subscribes to a Mosquitto broker topic, the Code node converts the payload to JSON, and HTTP Request writes the time series to InfluxDB. This is the collection layer: raw events are accumulated in a time-series database, on top of which threshold checks and alerts are built.
How this maps to MES, 1C, and sensors
Event sources in manufacturing are heterogeneous, and n8n handles each with its own protocol:
- Sensors and controllers — via MQTT Trigger: the node subscribes to a broker topic and reads the payload on each publish. This is a standard channel for industrial IoT and M2M exchange (oneclickitsolution.com).
- MES / SCADA — via webhook: the system POSTs the event to an n8n URL, which then processes and routes it. This is the community-recommended way to integrate shop-floor systems (oneclickitsolution.com).
- 1C and ERP — via HTTP requests to REST/OData endpoints or by reading an intermediate DB (PostgreSQL/MySQL nodes), from which n8n pulls counters for defects, downtime, and orders.
For manufacturing, architectural discipline matters: n8n does not need to be embedded into MES or 1C and patch their core. It lives alongside them as a separate orchestration service, communicates through standard protocols (MQTT, webhook, REST), and is therefore decoupled: it can be replaced or handed off to another team without rewriting the accounting system. This reduces risk and maintenance cost compared with custom integrations.
Routing and escalation
The value is not in "sending a message," but in sending to the right recipient with the right urgency. A Switch node by severity level implements this directly: a critical deviation opens two channels at once (for example, email to the shift supervisor plus a messenger alert to the on-duty team), a warning goes only to the work chat, and normal values stay silent. Community materials describe extending the scheme with an AI agent that evaluates readings against thresholds, assigns severity itself, and chooses the escalation route (oneclickitsolution.com). In addition to the alert, n8n uses the same workflow to create an incident record in a log or table - a trace for investigation and MTTR calculation.
Business Outcome
What manufacturing gets, not "what the tool does":
- response in seconds instead of manual checks — a practical breakdown of a production-line scenario on n8n shows a workflow runtime of about 10 seconds and a roughly 90% reduction in response time to downtime (oneclickitsolution.com);
- fewer missed deviations — continuous automated monitoring instead of spot human checks;
- fact-based review — each incident is already recorded in a historical store (Google Sheets / InfluxDB / DB) with a timestamp and severity;
- no vendor lock-in — self-hosted open-source core and standard protocols.
Important note on the numbers: "~10 seconds" and "-90%" are figures from a specific public example, not a guarantee. The actual result depends on threshold quality, source latency, and escalation discipline. The right approach is to capture the baseline of current response time, then measure it after implementation.
Business process conclusion
The "response to a production incident" process is restructured as follows: event (sensor/MES/1C) -> collection and normalization in n8n -> threshold check and severity -> channel routing with escalation -> incident log entry. The manual step of "someone noticed and reported it" is removed from the critical path and remains only where a decision is needed, not problem detection. This shifts response from reactive workarounds to a controlled, measurable, and transferable automated loop.
