How to Set an MQTT Keepalive for a Cellular Link

Back to Blog

Understand What Keepalive Controls

Keepalive does two jobs. It tells the client to send a ping if it has published nothing for the interval, which proves the connection is still alive. And it tells the broker to consider the client gone if it hears nothing - not even a ping - for about one and a half times the interval. So one setting controls both your traffic floor and how fast a dead device is noticed.

That dual role is why keepalive is a tuning decision, not a default. A short interval detects a lost device quickly and holds the connection open reliably, but sends frequent pings. A long interval saves traffic but slows offline detection and risks the connection being torn down mid-idle. The offline-detection side ties directly into the MQTT last will and testament, which fires when the broker declares the client dead.

Find the Carrier NAT Idle Timeout

The hard constraint on a cellular link is the carrier's NAT idle timeout. Mobile networks map your device to a shared public address through NAT, and that mapping is torn down after a period of no traffic. If your keepalive is longer than that timeout, the connection silently dies during idle periods and the device only discovers it on the next publish, which then fails. The keepalive ping must come more often than the NAT timeout to keep the mapping alive.

The exact NAT timeout is carrier-specific and sometimes APN-specific, so treat it as a value to determine, not assume - your carrier or a field test tells you. Set the keepalive comfortably shorter than whatever that timeout turns out to be, with margin, because a keepalive right at the edge fails intermittently when the network is loaded. Related link-behavior knobs live in reconnect backoff for telemetry clients.

Balance Data and Battery Against Detection Speed

On a metered cellular plan and a solar-powered site, every keepalive ping costs a little data and a little energy. Multiply a short interval across a large fleet and it adds up, so do not set it shorter than the NAT constraint and your offline-detection requirement actually need. Let the offline-detection requirement set the floor: how fast must the system know a device died?

If you need to know within a couple of minutes, the keepalive and the resulting one-and-a-half-interval detection window must fit inside that. If a slower detection is acceptable, lengthen the keepalive toward the NAT limit and save the traffic. The right number is the longest interval that satisfies both the NAT timeout and your detection requirement - not the shortest you can imagine.

Set It Alongside Session and Will Behavior

Keepalive decides when the broker declares the client dead, which is exactly when it publishes the client's last will. So set the will topic and payload with the keepalive in mind: a fleet availability view is only as fast as the keepalive lets the death be detected. Pair a keepalive tuned for your detection window with a will message that flips a device-online status.

Also decide session behavior together. If the device uses a persistent session so queued messages survive a brief drop, the keepalive-driven death and the session expiry interact - the session outlives the connection by its own timer. Understand that split in MQTT session expiry and clean start so a device declared dead can still reclaim its queued messages on reconnect.

Verify on the Real Link

Test on the actual cellular connection, not a bench LAN. Let a device sit idle past its keepalive interval several times and confirm the connection survives - if it dies during idle, the NAT timeout is shorter than your keepalive and you must reduce it. Then kill the device abruptly and time how long until the broker publishes its will; that is your real offline-detection latency.

Confirm both directions under a degraded signal, not just full bars, because a marginal link both slows pings and stresses NAT. A keepalive that holds at full signal but drops on the fringe of coverage is not tuned for the field. The interval that survives idle and detects death within your window on a weak signal is the one to deploy.

Common Mistakes

The signature cellular mistake is a keepalive longer than the carrier NAT timeout, giving a device that looks connected but whose connection has been quietly severed until the next failed publish. The opposite mistake is a needlessly short keepalive that drains a solar site's data and battery for detection speed nobody required.

Another is tuning keepalive on a LAN and shipping that value to the field, where the NAT constraint it never saw breaks it. And do not set keepalive without deciding the will and session behavior it drives - the three together define how the fleet sees a device come and go.

Frequently Asked Questions