When a Sparkplug edge node shows STALE or OFFLINE in the host application, the host is telling you it has lost confidence in that node's data, and the reason is rarely as simple as the node being unplugged. Sparkplug is built on MQTT birth and death messages, sequence numbers, and a broker session, and any of those can misfire and take a node offline while the equipment underneath is running perfectly. This guide walks the recovery process by finding the real trigger, whether a keep-alive timeout fired the death certificate, a sequence gap forced a rebirth, a duplicate client ID stole the session, or QoS and session settings dropped messages, and getting the node cleanly back to ONLINE.
Troubleshoot a Sparkplug node going offline in one line: A Sparkplug edge node shows STALE or OFFLINE when the host stops trusting its data, and the usual triggers are a keep-alive timeout on a flaky link firing the last will and NDEATH, sequence-number gaps that force a rebirth, a duplicate client ID stealing the broker session, or QoS and session settings that drop messages. Diagnose by finding which trigger actually fired: check the link and keep-alive against the drop timing, look for sequence gaps and rebirth requests, confirm client IDs are unique, and verify QoS and clean-session settings, then let the node re-birth cleanly.
The symptom is a node that the host marks STALE or OFFLINE while its data stops updating, sometimes flapping between online and offline. To read this you have to understand how Sparkplug declares a node alive or dead. When a node connects it publishes an NBIRTH, a birth certificate carrying its full set of metrics, and the host treats it as online. It also registers a last will and testament with the broker at connect time, an NDEATH message the broker will publish on the node's behalf if the connection is lost. So when the host sees OFFLINE, it is almost always because that NDEATH fired, meaning the broker decided the node's connection was gone. The NBIRTH and NDEATH concept page defines these; the diagnostic question is what made the broker publish the death certificate.
The most common answer is the keep-alive. An MQTT client and broker agree on a keep-alive interval, and if the broker does not hear from the client within roughly one and a half of that interval, it considers the client gone and publishes the last will, the NDEATH. On a flaky cellular or radio link, a brief loss of connectivity or a stalled packet can exceed the keep-alive even though the node and its equipment are fine, so the broker declares it dead and the host shows OFFLINE. When drops line up with the keep-alive interval and the link is marginal, the keep-alive expiring on a lossy connection is the trigger, and the node itself never actually failed.
This distinction is the crux of the whole troubleshoot: the node going OFFLINE in the host is an MQTT-session event, not necessarily an equipment event. The plant floor device can be running, its PLC scanning, its I/O healthy, while the node shows offline purely because the MQTT connection to the broker was lost long enough for the death certificate to fire. Separating a session-level drop from a genuine node failure early stops you from dispatching someone to a healthy site or from ignoring a real fault, and it points the rest of the recovery at the link, the identity, or the message flow rather than at the equipment.
If the link is not the cause, look at the Sparkplug sequence numbers, which are how the host detects that it may have missed data. Every Sparkplug message from a node carries an incrementing sequence number, and the host watches for that sequence to advance by one each time. If it sees a gap, a number out of order or skipped, it knows a message went missing and can no longer trust its picture of the node, so it issues a rebirth request asking the node to republish its full state. A node that keeps triggering rebirths, or that briefly goes stale and recovers, is often suffering sequence gaps from dropped messages rather than a full disconnect. The sequence-number and rebirth concept pages describe this mechanism; the recovery is to fix why messages are being lost and let the rebirth restore a clean, complete state.
A subtler and often-missed cause is a duplicate MQTT client ID. Every client that connects to a broker must have a unique client ID, and if two nodes, or a node and a stray test client or a duplicated configuration, connect with the same ID, the broker will disconnect the earlier one to make room for the newer, because it assumes the same client is reconnecting. The result is two clients endlessly kicking each other off, each connection firing the other's death certificate, so the node appears to flap offline and online on a rhythm that has nothing to do with the link or the equipment. If a node drops in a regular back-and-forth pattern, hunt for a second client using the same ID and make every client ID unique.
Finally, check QoS and session settings, because they govern whether messages survive a brief disconnect. The MQTT quality-of-service level determines delivery guarantees, and the clean-session or persistent-session setting determines whether the broker holds queued messages and subscriptions across a reconnect. A configuration that uses a clean session or a QoS that does not retry can silently drop messages during a momentary link glitch, producing the sequence gaps and staleness above, whereas persistent sessions and appropriate QoS let the connection ride through short interruptions. Reviewing these settings, together with any birth and death topic configuration, often resolves a node that goes stale on every minor network hiccup.
Recovery follows from the trigger you identified rather than from a blanket restart. If the keep-alive on a flaky link fired the NDEATH, the fix is on the link and the keep-alive tuning: stabilise the connection, and set a keep-alive long enough to ride out the link's normal brief interruptions without being so long that a truly dead node goes unnoticed. If sequence gaps forced rebirths, fix the message loss, and let the host's rebirth request pull a fresh, complete NBIRTH so the node is fully resynchronised. If a duplicate client ID was stealing the session, making the IDs unique stops the flapping immediately. In every case the clean end state is the node reconnecting, publishing its NBIRTH, and the host marking it ONLINE with a complete and current metric set.
It helps to lean on Sparkplug's own recovery design rather than fighting it. The birth-and-death model exists precisely so a host can always recover a node's full state by requesting a rebirth, and sequence numbers exist so the host knows when it needs to. When a node comes back after any drop, the correct behaviour is a fresh NBIRTH and, if the host had missed messages, a rebirth to guarantee nothing is stale. Understanding that OFFLINE and STALE are the system working as designed, flagging that it cannot currently trust the data, reframes the troubleshoot from suppressing the state to fixing what makes the state fire so often.
For SCADA and cloud monitoring this matters because a flapping node undermines exactly what MQTT Sparkplug is meant to provide: a trustworthy, event-driven picture of the edge. A host or cloud SCADA platform such as Merobix acting as the Sparkplug consumer relies on birth and death and sequence integrity to know a node's state, so a node that keeps going offline either raises false alarms or, worse, teaches operators to ignore an offline indicator that might one day be real. Stabilising the underlying MQTT link, ensuring unique client identities, and setting keep-alive, QoS, and session parameters to match the site's connectivity is what keeps edge nodes reliably online, so that an OFFLINE in the host genuinely means the node needs attention rather than the network merely hiccuped.
Because a node going OFFLINE in the host is an MQTT-session event, not necessarily an equipment event. When the broker loses the node's connection, usually because the keep-alive expired on a flaky link, it publishes the node's last will, the NDEATH, and the host marks it offline even though the PLC and I/O are fine. Check whether the drops line up with the keep-alive interval on a marginal link before assuming the equipment failed.
A regular back-and-forth flap most often points to a duplicate MQTT client ID. Two clients connecting with the same ID cause the broker to disconnect the earlier one each time the newer connects, so they endlessly kick each other off and each disconnect fires the other's death certificate. Hunt for a second client, stray test tool, or duplicated configuration using the same ID and make every client ID unique.
Every Sparkplug message carries an incrementing sequence number, and the host expects it to advance by one each time. If the host sees a gap it knows a message was missed and can no longer trust its view of the node, so it issues a rebirth request asking the node to republish its full state in a fresh birth message. Frequent rebirths usually mean messages are being dropped, so fix the message loss and let the rebirth restore a clean state.
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.