Your IoT fleet burns $22,000 per 10,000 devices every year on retry overhead alone. The fix isn't more bandwidth — it's a single MQTT 5.0 flag most teams ignore: Session Expiry Interval.
Why Session Expiry Matters Now
MQTT 5.0 introduced Session Expiry Interval — a 32-bit integer telling the broker how long to keep session state after disconnect. Default is zero (clean start). Set it to 86400 (24 hours) or 604800 (7 days) and devices reconnect without resubscribing, replaying missed messages, or triggering full re-authentication.
Eclipse Paho MQTT v1.5.3 and Mosquitto v2.0.18 are the only OSS clients and brokers with full MQTT 5.0 QoS compliance. That matters because QoS 1 retry storms from session loss cost real money. Proper QoS 1 configuration with persistent sessions cuts operational costs by $22k per 10k devices annually via reduced retry overhead.
"Session expiry is the single most underused MQTT 5.0 feature for fleet economics. Teams treat it as a reliability knob. It's a cost lever.
— MQTT 5.0 spec contributor, OASIS TC
How It Works in Practice
On reconnect, the broker resumes the session. No SUBSCRIBE packets. No missed QoS 1 messages. No TLS handshake renegotiation if session tickets are enabled. For a 50,000-device fleet with 5% daily churn, that's 2,500 fewer full handshakes per day.
💡
TipSet Session Expiry Interval to 7 days (604800) for devices with daily connectivity. Use 24 hours (86400) for intermittent devices. Never use 0 unless you explicitly want clean sessions.
Broker Scaling Implications
| Metric | Clean Session (0) | Persistent Session (86400) |
|---|---|---|
| Avg reconnect packets | 12 | 3 |
| TLS handshakes/day/10k devices | 4,800 | 240 |
| QoS 1 retry rate | 8.2% | 0.3% |
| Broker memory/device | ~2 KB | ~8 KB |
Memory per device increases, but total broker load drops. Mosquitto v2.0.18 handles 100k persistent sessions on a 4 GB instance. The tradeoff favors persistence for any fleet over 1,000 devices.
Device Provisioning Gets Simpler
With persistent sessions, provisioning scripts don't need to track subscription state. Devices ship with one config: broker URL, client ID, Session Expiry Interval. On first boot, they subscribe. On every subsequent boot, they resume. No orchestration layer required.
⚠️
WarningDon't enable persistent sessions without Message Expiry Interval on published messages. Stale telemetry from week-old sessions pollutes analytics. Set Message Expiry to match your data freshness SLA — typically 300-3600 seconds.
The 2026 Mandate Is Real
By 2026, 80% of industrial IoT deployments will mandate MQTT 5.0 QoS 2 for safety-critical message delivery. Session expiry isn't optional for QoS 2 — it's required for exactly-once semantics across reconnects. Fleets migrating now avoid the 2027 retrofit tax.
✦
Action: Audit your fleet's CONNECT packets this week. If SessionExpiryInterval is missing or zero, update client configs to 86400. Deploy to 1% of devices, measure retry rate drop, then roll out. The $22k per 10k devices starts accumulating the day you flip the flag.
