MQTT Keep-Alive and Ping Explained

TCP can lie. A connection can look open to one side while the other has silently vanished — a crashed device, a dropped Wi-Fi link, a firewall that quietly killed an idle session. MQTT keep-alive is the mechanism that lets the broker tell a live client from a dead one.

How keep-alive works

The client declares a keep-alive interval (0–65,535 seconds) in its CONNECT packet. It then promises to send some packet — a publish, a subscribe, or, if it has nothing else to say, a PINGREQ — within every interval. The broker answers each PINGREQ with a PINGRESP. Any packet resets the timer.

If the broker hears nothing for 1.5× the interval, it assumes the client is gone and closes the connection. With a 60-second keep-alive, the client must be heard from at least every 90 seconds.

Server keep-alive (MQTT 5.0)

MQTT 5.0 lets the broker push back on the interval a client asks for. If the requested keep-alive is longer than the broker is willing to allow, it returns its own Server Keep Alive value in the CONNACK, and the client must adopt that interval instead. This caps how long a connection can sit idle before the broker is prepared to reclaim it, no matter what the client proposed. MQTT 3.1.1 has no such property, so there the client’s value always stands.

Why it matters: half-open connections

Without keep-alive, a broker can accumulate half-open connections — sessions it believes are active but whose clients are long gone. These waste resources and leave stale sessions around. Keep-alive forces clients to prove they're alive, so the broker can reclaim dead connections promptly.

Choosing a keep-alive value

Shorter intervals detect failures faster but add ping traffic and wake battery-powered devices more often; longer intervals are lighter but slower to notice a dropped client. Match the interval to how quickly you need to detect a disconnect. Devices that already send data at a steady rate may not need a short keep-alive at all, since their normal traffic keeps the connection active.

Keep-alive in TBMQ

TBMQ monitors keep-alive per connection (checking on an interval set by MQTT_KEEP_ALIVE_MONITORING_DELAY_MS, every second by default). On timeout it closes the connection with reason KEEP_ALIVE_TIMEOUT and publishes the client's Last Will if one was set. For MQTT 5.0 clients it also enforces a Server Keep Alive: a requested interval above 600 seconds (10 minutes) is capped to that maximum and returned in the CONNACK. See the keep-alive docs for the full behavior, including client take-over when the same client ID reconnects.