An idle connection can be silently killed by the network between two systems long before either notices. A keepalive is the low-cost trick that keeps a quiet link both open and observably alive.
Keepalive in one line: A keepalive is a small periodic message sent over an otherwise idle connection to keep it open and to confirm the other end is still reachable. On event-driven SCADA links that go quiet between changes, intermediate devices like firewalls, NAT routers, and cellular carriers will drop a connection they think is dead. Keepalives generate just enough traffic to prevent that timeout and to detect a truly broken link quickly.
When SCADA uses report-by-exception, a connection can sit with no data for long stretches - nothing changed, so nothing was sent. The two endpoints consider the connection perfectly healthy. But the devices in between do not. Firewalls and NAT routers track active connections in a table with an idle timeout; when they see no traffic for a few minutes, they discard the entry to reclaim resources. Cellular carriers do the same to conserve network state.
Once that middle device forgets the connection, the next real message has nowhere to go, and the endpoints only discover the loss when they finally try to communicate - potentially minutes after it broke. On an intermittent field link this creates confusing, hard-to-diagnose dropouts that look like device faults but are really the network aging out an idle session.
A keepalive fixes both halves of the problem. By sending a tiny message on an interval shorter than the network's idle timeout, it keeps the connection entry fresh in every firewall and NAT device along the path, so the session is never aged out. TCP has a built-in keepalive for this, and application protocols like OPC UA and MQTT define their own keepalive or session-timeout intervals.
The keepalive also serves as a liveness check. If a keepalive is sent and no response comes back within the expected window, the sender learns the link is broken immediately rather than waiting for the next real data. This gives fast, deterministic failure detection on connections that would otherwise appear fine until the moment they are needed. The interval is chosen to sit comfortably under the shortest idle timeout in the path while adding negligible traffic.
Remote sites almost always sit behind carrier NAT on a cellular network and behind at least one firewall, and they typically use event-driven reporting that leaves the link quiet. That combination is exactly the scenario where idle timeouts bite. Tuning keepalives so they beat the carrier and firewall timeouts is a routine part of getting a remote SCADA connection to stay reliably up.
Keepalives pair naturally with outbound-only connection designs. A field device that opens an outbound, persistent connection to a central or cloud system must keep that single connection alive to receive commands and to be trusted as reachable; the keepalive is what holds it open through the carrier's aggressive idle timeouts without needing any inbound port.
They also complement heartbeats and watchdogs. A keepalive maintains the transport connection at the network layer; a heartbeat proves the application above it is producing fresh data. Together they distinguish a healthy-but-quiet link from one that has silently died, which is essential for trusting a field of intermittently connected sites.
Firewalls, NAT routers, and cellular carriers track active connections in tables with idle timeouts and discard entries that see no traffic. Once the entry is gone, the connection is effectively dead even though both endpoints still think it is open.
They overlap but differ in layer. A keepalive maintains and checks the transport connection itself, often at the TCP or protocol-session level. A heartbeat proves the application is alive and producing fresh data. Reliable systems commonly use both.
Set it shorter than the tightest idle timeout in the network path - typically the cellular carrier's or firewall's - so the connection is refreshed before any device ages it out, while keeping the added traffic negligible. On cellular this often means tens of seconds to a couple of minutes.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.