A device that connects, works for a while, drops, reconnects and repeats is one of the most common and most frustrating IoT faults. The symptoms look the same from the dashboard, with gaps in data and a high reconnect count, but the causes are very different. Treat it like a diagnosis: gather the pattern first, then match it to the likely cause.

Read the Pattern Before Touching Anything

Pull the connection logs from your broker or platform for a single affected device and look at three things.

How long do sessions last before dropping? If they last nearly the same duration every time, a timer is involved: keepalive, a NAT timeout or a credential lifetime. If durations are random, think signal quality or instability.

What reason does the broker give? Most brokers and platforms log a disconnect reason, such as a keepalive timeout, authentication failure, a client taking over the session, or a protocol error. Platforms differ in wording, so check yours in its current documentation. This one field often settles the matter.

Is it one device, a group, or everyone? One device suggests hardware, placement or configuration. A group sharing a network provider, location, firmware or hardware revision suggests something shared. Everyone at once suggests the broker, certificates or a platform-side change.

Cause One: Two Devices, One Client ID

This is the sneaky one. In MQTT, a client identifier must be unique among connected clients. When a second client connects with the same identifier, the broker typically drops the first to admit the second. If both are trying to stay connected, they take turns kicking each other off in a loop.

It happens when firmware derives its identifier from something that is not truly unique, such as a hard-coded string, a model name or a default left in a cloned image. It also happens when a developer’s test setup uses a production identifier.

The tell is a very regular reconnect cadence and a disconnect reason that mentions session takeover. The fix is to derive the identifier from a unique hardware value or the provisioned device identity, and to check your fleet for duplicates.

Cause Two: Keepalive and Idle Networks

MQTT uses a keepalive interval: if the broker hears nothing from the client within roughly that interval, it considers the client gone. Meanwhile, mobile networks and home routers keep tables of active connections, and entries for idle ones expire. If the network’s timeout is shorter than your keepalive, the path silently closes before either end notices.

Result: the device thinks it is connected and publishes into nothing, until its next keepalive fails or the broker times it out. Sessions then end at about the same elapsed time, again and again.

Fix by setting the keepalive shorter than the shortest network timeout you expect. Cellular networks vary and can be aggressive, so measure on the actual carrier. Shorter keepalives cost battery and data, so balance them against your needs.

Cause Three: Credentials and Certificates

If sessions fail at connect time or end at a fixed moment, check credentials. Expired or soon-to-expire certificates are a classic, as are tokens with a fixed lifetime that the device does not renew. A clock that is wrong on the device can make otherwise valid certificates look expired or not yet valid.

Check the device’s time source first. Many embedded devices boot without a correct clock and need to fetch time before attempting a secure connection. If that order is wrong, the first handshake fails and retries can turn into a storm.

Cause Four: Weak Signal and Overloaded Links

Random drops that correlate with location, time of day or weather point at the radio. Signal strength readings in your heartbeat help confirm it. In congested networks, handshakes can time out under load.

Mitigations include better antenna placement, moving to a more appropriate connectivity option, and making the device resilient: exponential backoff with jitter on reconnect, and store-and-forward for readings generated while offline.

Cause Five: Broker or Platform Limits

Platforms enforce limits on message rate, message size, subscriptions per client and connection attempts. Exceeding one may cause the broker to disconnect the client. If a device has just started sending larger payloads or publishing faster after a firmware change, suspect this. Look up the current limits in your provider’s documentation, since they change.

Matching Symptom to Cause

Observed pattern	Likely cause	First thing to check
Regular loop, takeover reason	Duplicate client ID	Identifier derivation across the fleet
Fixed session length, timeout reason	Keepalive versus network timeout	Keepalive setting and carrier behavior
Fails at connect, or at fixed expiry	Certificate, token or clock	Expiry dates and device time
Random drops tied to site	Signal or congestion	Signal readings and location
Starts after firmware change	Message limits or protocol use	Payload size and publish rate

A Hypothetical Example

A team notices a batch of new devices reconnecting about every minute. The reason in the broker log says another client connected with the same identifier. Investigation shows the manufacturing process flashed every unit in the batch with the same configuration file, including an identifier meant to be replaced during provisioning. Because the provisioning step was skipped for the batch, all of them shared the same name and evicted each other. Re-running provisioning fixed it, and a pre-shipment check was added to reject duplicates.

Reconnect Behavior You Should Build In

Whatever the cause, a device should reconnect politely. Use exponential backoff with random jitter so a fleet does not stampede the broker after an outage. Cap the backoff at a sensible maximum. Log the last disconnect reason on the device and report it after reconnecting, so the cloud sees both sides of the story.

Frequently Asked Questions

What is a good keepalive value? There is no universal answer. It should be shorter than the shortest idle timeout on the network path, and long enough not to waste power. Test on the real network.

Why does the dashboard say connected when the device is not? Connection state is based on what the broker knows. If the network path died silently, it can take until the keepalive expires for the broker to notice.

Does a persistent session help? It lets the broker retain subscriptions and queued messages across reconnects, which helps with command delivery. It does not prevent the drops themselves.

How do I find duplicate client IDs? Compare identifiers across your registry and look for devices that show frequent takeover disconnects. Also review how firmware generates the identifier.

Should I just retry faster? No. Rapid retries worsen congestion and can trigger rate limits. Back off with jitter.

Next Step

Choose one device that is dropping and pull its last twenty disconnects with their reasons and timestamps. Write down the session lengths. That small table will usually point straight to one of the five causes above.