Can we get production alerts without sending our data to a cloud?

What can trigger an alert?

Most alerts answer the same floor-level question: has something gone wrong that a person needs to act on, and how long has it been that way? The rules people actually write look like this.

• A line down longer than a set number of minutes.
• A stop sitting open with no reason code on it.
• A run going slower than it should, with the slow cycles adding up.
• An OEE score, or one of its parts (availability, performance, quality), below the band you set for the shift.
• A shift closing out with its headline numbers, sent to the people who were not there.

A rule is built from a target, a condition and a list of recipients. The condition combines the metrics a device reports, the process states it can be in, your own downtime reason codes, a threshold band and a duration, so "down more than fifteen minutes with no reason entered" is one rule rather than a report somebody has to remember to open. The target is a place in your device hierarchy: a plant, an area, a line or a single machine.

The message that goes out names the device, the metric, the value it reached, the band it crossed and how long the condition has held. Each rule carries a severity, so a stopped line and a drifting quality number do not arrive looking identical.

How does the alert leave the building?

Everything below describes the arrangement this page is written for: the software and its database installed on a server on your own plant network. OEE IntelliSuite can also be hosted for you, and the technical specifications page covers both. On a hosted install the boundary sits somewhere else, so read this section as the answer for the in-plant case rather than as the answer for yours.

This is the part worth reading twice, because it is the honest hard part. On the in-plant install the production database stays on your server in every case below. What varies is whether the text of an alert, and the address it is sent to, cross the boundary at all.

In-app banners: nothing leaves

The banner shows on screens signed in to your own instance, on the part of the plant the rule fired on. It never leaves the network, and it is the channel that works on a site with no route out at all. Which screens are subscribed is an administrator setting, so the person writing a rule never picks somebody's computer.

Email through your own relay: nothing leaves

You point the software at a mail server, its port, and the account it should send as. If that server is the relay already sitting in your own data center, the alert is an internal email and the boundary is never crossed. This is the answer for a plant whose rule is that nothing may leave, and it is worth checking whether you have such a relay before assuming you do not.

Email through a hosted mail service: the alert leaves, the database does not

Point the same setting at Microsoft 365 or Google Workspace and the alert becomes an ordinary company email. Be precise about what that means: the recipient address and the body of that one message, which names a machine and a number, go to your mail provider, the same way the rest of your mail already does. What stays put is everything behind it, the production database and the history every report is built from.

SMS: the message and the number leave, and there is no way around it

A text message to a personal phone has to reach a carrier, and carriers are outside every firewall. So the number and the text of that one message go to a messaging provider. There is no air-gapped version of this, and anyone who tells you otherwise is describing something else. What can be said is what happens to the number: the person who owns the phone enters it themselves and checks a consent box, it is stored in your own deployment, it is used only for these alerts, never for marketing, and STOP stops them. The full program disclosure is published.

Microsoft Teams: an outbound post to your own tenant

Somebody on your side creates the webhook inside your Teams tenant and saves the URL. The alert is then an outbound HTTPS post from your server to Microsoft, carrying the same short message. That URL is a credential in its own right, so it is stored write-only: after it is saved it is never shown back, and only its hostname is displayed.

Slack and Discord: a post to a workspace that is not on your network

Both are hosted chat services, so a message to either one leaves the plant by definition. What crosses is the same short line about one machine, and the workspace or channel it is addressed to. Neither has an in-plant version to point a reviewer at, so if the site rule is that nothing may leave, these are not the channels for it: the banner and the internal relay are the two that satisfy that rule.

On every channel that does reach outside, which is hosted mail, SMS, Teams, Slack and Discord, what crosses is the text of one alert and the address, phone number or channel it is going to, and that text is a line about one machine. On a banner or an internal relay, nothing crosses at all. On no channel do the counts, the states, the reasons, the jobs or the history behind every report leave the server the suite is installed on.

What does IT have to allow?

Start with the shape of it, because it is the first question a reviewer asks: alert delivery is outbound, and nothing about it requires an inbound connection from the internet.

The host itself needs to:

• reach the Vorne XL devices and any other shop-floor sources on the plant network, from a static or reserved address with a hostname people can type
• accept HTTP and HTTPS from the desktops, laptops, tablets, phones and floor displays that use it, with a TLS certificate path for production and firewall rules for the app ports or a reverse proxy
• reach an SMTP relay, which is what email alerts and scheduled reports go through
• reach a provider for SMS, and only if you enable SMS
• reach Microsoft, Slack or Discord for a chat alert, and only for the chat channels you turn on
• keep time in step through NTP or whatever the site standard is

Support access is a VPN with SSH or RDP, or an approved outbound tunnel where direct inbound access is not on the table. A site with no internet installs from an offline bundle and takes updates through a manual transfer path. Logs and their retention are local, and anything shipped to central monitoring goes only when site IT approves it. All of that is on the technical specifications page, alongside the server sizing, which is the page to hand a reviewer rather than a summary of it.

Who gets the alert, and who acknowledges it?

Recipients are named on the rule, as addresses and numbers, so the people who own a line get the alerts for that line instead of a distribution list getting everything. Banners follow the rule's target rather than a recipient list, which is how a screen on the floor shows the thing that just happened next to it.

A rule either fires once or repeats while the condition holds, at an interval you set, which is the practical form of escalation: an alert nobody has dealt with keeps arriving. It can also send a recovered notice when the condition clears, so a line coming back is not a phone call. Quiet hours are an active window on the rule, a start and end time plus the days it applies to, and outside that window the rule is not evaluated at all rather than evaluated and swallowed.

Acknowledgement is deliberate: a banner can be set to stay until somebody acts on it rather than fading. And every delivery is recorded with its status, searchable and filterable, so a message that failed shows up as failed instead of quietly not existing. That record is usually what an auditor is really asking for.

How is this different from XL Enterprise alerts?

The XL device on the line is a complete thing on its own. Vorne's own site says there is no software to install and no servers to maintain, and that the embedded webserver puts the data in front of everyone on the network.

Alerting is the part that reaches past the network. Vorne describes XL Enterprise as the cloud component of its Industrial IoT platform, receiving real-time data from XL devices to send alerts and emailed shift reports, based on production metrics, stops, slow running, changeover timing and OEE below expectations. Vorne is also clear that it is optional: in their words, unlike most cloud applications for manufacturing, XL Enterprise is entirely optional, and many of its services are free. Plenty of plants use it and should.

The plants this page is written for are the ones where that decision has already been made for them, by a policy that says production data does not leave the building. OEE IntelliSuite sits on the same network as the XL 800, XL 810 and XL HD boards, reads them there, and runs the rules and channels described above from a server you own. It is an addition to the boards, not a replacement for them.