Plain MQTT has no built-in idea of a device coming online or going offline in a structured way - it just moves messages. Sparkplug B adds that missing concept with a pair of lifecycle messages. When an edge node connects, it announces itself with an NBIRTH that publishes its full set of metrics; when it disconnects ungracefully, an NDEATH tells the system it is gone. This guide explains what a birth certificate contains and why every metric must appear in it, how NDEATH is wired into MQTT's last-will mechanism, how a host application detects a stale node, and the role of the STATE topic in the overall session model.
NBIRTH and NDEATH in one line: In Sparkplug B, an NBIRTH is the message an edge node publishes when it comes online - its birth certificate, which declares every metric the node will report, along with each metric's alias and initial value. An NDEATH is the message that signals the node has gone offline; it is registered as the node's MQTT last will so the broker publishes it automatically if the node disconnects ungracefully. Together they give the host a clear, structured view of when a node is alive and when it has died.
When a Sparkplug edge node connects, the first data message it must publish is an NBIRTH - a node birth. This is not a lightweight hello; it is a complete declaration of everything the node is going to talk about. The NBIRTH lists every metric the node will report during this session, and for each metric it includes the name, the data type, an assigned numeric alias, and a current value. In effect the node hands the host a full catalog of itself at the moment it comes online, so the host knows the entire shape of the data before any ongoing updates arrive.
The rule that makes this work is strict: every metric the node will ever publish in the session must appear in the NBIRTH. A node cannot introduce a new metric mid-session out of nowhere, because the host builds its model of the node from the birth certificate, and a metric the host never saw at birth has no definition to attach an update to. This all-metrics-at-birth requirement is what lets the rest of the session be efficient - once the host has the full catalog, later data messages can be lean, referencing metrics by their short aliases rather than repeating full names and type information every time.
The NBIRTH therefore serves as the single source of truth for the node's structure. It resets the host's understanding: on receiving a fresh NBIRTH, the host discards any previous state for that node and rebuilds its model from what the birth declares. This is why a birth certificate is emitted not only on first connect but again whenever the node needs the host to resynchronize - a rebirth is simply another NBIRTH that re-establishes the complete, authoritative picture of the node from scratch.
The counterpart to birth is death, and Sparkplug handles it with a clever use of a standard MQTT feature. When an edge node connects to the broker, it registers an NDEATH message as its last will and testament. The last will is a message the client hands to the broker at connect time with instructions to publish it automatically if the client disconnects ungracefully - if it drops off the network, loses power, or its connection times out without a proper disconnect. By making NDEATH the last will, Sparkplug ensures that a node that dies unexpectedly still gets an announcement of its death, generated by the broker on the node's behalf.
This is what lets a host reliably know a node has gone offline without having to poll it. The host does not have to infer death from silence and guess how long is too long; when a node's connection drops, the broker publishes that node's NDEATH, and the host receives an explicit signal that the node is no longer alive. On receiving an NDEATH, the host marks that node and all of its metrics as stale - it stops trusting the last-known values as current, because it now knows the source of those values has gone dark. Operators then see clearly that a node is offline rather than staring at frozen values that look live but are not.
The pairing of last-will NDEATH with birth is what gives Sparkplug its clean session semantics on top of MQTT. A node lives from its NBIRTH to its NDEATH, and the host tracks that lifespan explicitly. If a node reconnects after a death, it publishes a new NBIRTH, the host rebuilds its model, and the cycle begins again. A sequence-number scheme woven through the messages, starting fresh at each birth, additionally lets the host confirm that the death and birth line up correctly and that it has not missed the transition, which keeps the alive-or-dead determination trustworthy even across messy disconnects.
This birth-and-death model is exactly what makes Sparkplug so well suited to cloud SCADA over MQTT. A cloud platform such as Merobix acting as a Sparkplug host consumes NBIRTH messages to learn each edge node's full metric set automatically - it does not need a manually maintained tag list per device, because the node describes itself on connect. When an NDEATH arrives, the platform immediately flags that node's data as stale and can alert operators that a remote asset has gone offline, so the difference between a live value and a value from a node that died an hour ago is never ambiguous on the screen.
There is a matching concept at the top of the hierarchy for the host itself: the STATE topic. Just as edge nodes announce their aliveness through birth and death, the primary host application publishes its own online-or-offline status on a STATE topic, using MQTT's last will so that if the host disconnects, its offline state is announced automatically too. This lets edge nodes know whether the host that is supposed to be consuming their data is actually present. If the host goes offline, nodes can react appropriately rather than publishing into a void, and when the host returns, the coordinated state handling ensures both sides resynchronize cleanly.
Taken together, NBIRTH, NDEATH, and STATE turn a bare MQTT broker into a system with a genuine, shared understanding of what is alive. For distributed oil and gas assets - well pads, compressor stations, remote metering - where connections come and go and operators need to trust that a reading reflects the real, current state of the field, this lifecycle is the foundation. It is the difference between a monitoring picture that honestly shows which nodes are reporting and which have died, and one that quietly presents stale numbers as if the whole field were still live.
It is the birth certificate an edge node publishes when it comes online. The NBIRTH declares every metric the node will report during the session, including each metric's name, data type, numeric alias, and current value. It gives the host the full catalog of the node up front, so later data messages can reference metrics by short aliases. A fresh NBIRTH also resets the host's model of the node.
So that a node which disconnects ungracefully still gets its death announced. The MQTT last will is a message the broker publishes automatically if a client drops without a clean disconnect. By registering NDEATH as its last will, an edge node ensures that if it loses power or its connection times out, the broker sends the NDEATH on its behalf, letting the host learn the node is offline rather than guessing from silence.
It receives the node's NDEATH message, which the broker publishes as the node's last will when the connection drops. On receiving it, the host marks that node and all its metrics as stale and stops treating the last-known values as current. This gives an explicit offline signal instead of forcing the host to infer death from a lack of updates, so operators see clearly that a node has gone dark.
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.