Monitoring needs a network. It does not need the internet.
What works with no connection at all, the three arrangements plants actually use, and the network-interruption test worth demanding during any pilot.
A large number of Indian plants either have no reliable internet at the machine, or have a deliberate policy that production equipment is not internet-connected. Both are entirely workable, and in the second case the policy is usually correct.
Machine monitoring does not require the internet. It requires a network — which is a different thing, and the distinction is worth being precise about when an IT or security team is in the room.
The distinction that settles most objections.
Layers 1 and 2 constitute a complete working monitoring system. Layer 3 adds convenience — WhatsApp alerts, access from home, remote support — and is entirely optional. Plants that decline it lose notifications, not measurement.
With an on-premises server on the plant LAN, everything that constitutes monitoring continues: machines are read, states and counts are recorded, OEE and downtime are computed, dashboards load on any browser in the building, shop-floor TV screens update, route cards progress, and reports can be generated and exported.
What you give up is anything that crosses the boundary: outbound WhatsApp and email alerts, access from outside the plant, and remote diagnostic support from us. Where a plant wants alerts without internet, local mechanisms remain — an andon screen, a siren driven from a gateway output, or a supervisor's browser on the same network.
In order of how common they are.
| Arrangement | How it works | Suits |
|---|---|---|
| Fully isolated | No connection out of the plant at all. Monitoring is entirely local. | Defence-linked suppliers and plants with strict customer data clauses |
| Isolated machines, connected server | Machines sit on a separate network segment with no route out; the server has controlled internet for alerts and updates. | The most common arrangement, and usually the right balance |
| Intermittent | Connectivity exists but is unreliable. The system buffers and syncs when the link returns. | Plants in industrial estates with poor connectivity |
An unreliable link is a harder engineering problem than no link at all, because a system that has not planned for it produces a record with invisible holes. Events are timestamped at the machine and buffered locally, then delivered when the link returns, landing in the correct place in the timeline rather than bunching at the moment of reconnection.
If you are evaluating a system for a site like this, ask for the network-interruption test during the pilot: disconnect for ten minutes mid-shift and inspect the timeline afterwards. It is the single most informative five minutes of any evaluation. The mechanics are covered in CNC machine data acquisition.
An IT team asking about internet is generally asking a broader question: what can reach the machines, and what leaves the plant. On-premises deployment with a segmented machine network answers both narrowly — machines are read, never written to, and production data stays on a server you own.
That conversation is worth having properly rather than deflecting, because unresolved OT security concerns kill monitoring projects late, after budget has been committed. It is covered in industrial cybersecurity for machine monitoring, and the commercial framing is on the on-premises page.