Why MQTT Last Will Testament Isn't Enough for Production IoT (And What We Built Instead)

Anil Saithana — Sun, 22 Feb 2026 06:10:54 +0000

Why MQTT Last Will Testament Isn't Enough for Production IoT (And What We Built Instead)

I spent 7 years building cloud backends — but when I tried connecting real hardware (ESP32s in my home), I hit a wall:

"My device shows 'connected' in AWS IoT Core... but hasn't reported data in 4 hours. Is it hung? Dead? Or just offline?"

Turns out: MQTT's Last Will Testament (LWT) lies to you.

The Lie: "Connected" ≠ Alive

LWT triggers only on TCP disconnect. But real devices fail silently:

WiFi drops but TCP socket stays open (NAT timeout = 5+ minutes)
Device freezes but doesn't reboot (watchdog failed)
Sensor loop crashes but MQTT client still "connected"

Result? Your dashboard shows "✅ Online" while the device hasn't sent data since yesterday.

Our Fix: Application-Level Heartbeats + Stateful ACKs

We built a lightweight Spring Boot backend (hear-beat) that treats telemetry as heartbeat pulses — not just data.

Device → [temp=28°C, ts=1708512000] → Backend
Backend → "ACK @ 1708512000" → Device

1. Offline detection = missed heartbeat window

// DeviceRegistry.java
if (System.currentTimeMillis() - lastHeartbeat > OFFLINE_THRESHOLD) {
    markDeviceOffline(deviceId); // Not TCP disconnect — actual silence
}

2. Command safety via ACK loop

// CommandService.java
sendCommand(deviceId, "REBOOT");
waitForAck(deviceId, timeout=30s); // Did it *execute*? Not just "received"

3. REST control plane + MQTT data plane

Mobile apps talk REST (POST /devices/{id}/command)
Devices talk MQTT (iot/device/{id}/cmd)
Backend bridges both → clean separation

Why This Matters for Real Deployments

Scenario	LWT Says	Our Heartbeat Says
Device froze (no reboot)	✅ Connected	❌ Offline (no heartbeat in 90s)
WiFi dropped in rural field	✅ Connected (TCP alive)	❌ Offline (no data in 2 mins)
Command sent but device crashed mid-execution	✅ Command delivered	❌ No ACK → retry/fail-safe

This isn't theory. I run this for my home sensors — and it catches failures LWT misses daily.

Try It Yourself

git clone https://github.com/AnilSaithana/hear-beat
cd hear-beat
docker-compose up  # Runs Spring Boot + MQTT broker

ESP32 firmware example included in /firmware folder.

I built this because production IoT fails in the gaps between cloud and hardware.

If you've felt this pain — DM me. I'd love to hear your war stories.

DEV Community: Anil Saithana

Why MQTT Last Will Testament Isn't Enough for Production IoT (And What We Built Instead)

Why MQTT Last Will Testament Isn't Enough for Production IoT (And What We Built Instead)

The Lie: "Connected" ≠ Alive

Our Fix: Application-Level Heartbeats + Stateful ACKs

1. Offline detection = missed heartbeat window

2. Command safety via ACK loop

3. REST control plane + MQTT data plane

Why This Matters for Real Deployments

Try It Yourself