I measured this on our trailer trackers last year because our carrier bill was silly. Rough numbers from packet captures on a SIM7600, TLS 1.2, the platform’s broker:

• full reconnect (TCP + TLS handshake with certificate chain + CONNECT + SUBSCRIBEs): about 5 to 6 KB
• one keepalive round trip (PINGREQ/PINGRESP inside TLS, plus TCP/IP headers and ACKs): roughly 150 to 200 bytes
• your 80-byte reading as a QoS 1 publish inside TLS with PUBACK: also a couple of hundred bytes

So reconnecting every 5 minutes would cost about 8,640 handshakes a month, 45+ MB. Way worse. Keepalive 60 is 43,200 pings a month, around 8 MB. That’s a big chunk of your 25 MB.

What worked for us:

Keepalive up to 300 s (the broker serves anything above its maximum at 300 anyway). That cuts pings by five. Check your carrier doesn’t drop idle NAT sessions faster; ours held 6 minutes, some drop at 2 to 4. If you see keepalive_timeout in the device’s Log tab, step it down.

Batch. Instead of one publish every 5 minutes, buffer 3 readings and send them as one array with timestamps (ESP32 has NTP, so ts is fine):

[{"ts":1762336800000,"values":{"flow":12.1,"pressure":2.4,"pump":1}},
 {"ts":1762337100000,"values":{"flow":12.3,"pressure":2.4,"pump":1}},
 {"ts":1762337400000,"values":{"flow":11.9,"pressure":2.3,"pump":1}}]

Same data, one publish, and it also counts as one message against the monthly quota instead of three.

Look for chatty extras. In our case the worst was the firmware sending client attributes (IP, RSSI, firmware version) on every publish. Only send them on change.

On offline: with Live connection as the online rule they stay online as long as the MQTT session is open, so with keepalive 300 nothing changes. If you ever do go connect-send-disconnect, switch them to a profile with Recent message, otherwise they’d show offline between sends.