Operations
Getting one phone to send one message is the easy part. Keeping a fleet of handsets alive for months — through reboots, OEM battery managers, carrier throttling and SIM expiry — is the part that needs operational habits.
What actually goes wrong
In rough order of how often it bites, the failures are not the ones the code worries about:
| Symptom | Usual cause |
|---|---|
| Device silently stops sending after hours or days | OEM battery management killed the foreground service |
Messages stick at sent, never delivered | The carrier route returns no delivery report; this is normal |
| Device shows offline but the phone looks fine | Wi-Fi captive portal, or a network that validates but does not route |
| Sends start failing in bulk | Carrier anti-spam throttling on a consumer plan |
| Device cannot reconnect after working fine | Credential revoked, or secret rotated on the server |
Only the last of those is a Luno bug surface. The rest are properties of running on consumer hardware and a consumer SIM, and the docs below are mostly about recognising them quickly.
A node that has been killed by the OS is not detectable from the server side as anything other than “offline”. Treat sustained offline time as an alert, not a curiosity — the watchdog revives the agent in most cases, but not all OEMs allow it.
Health signals worth alerting on
The node reports these continuously; your backend decides which matter.
- Presence. Missing heartbeats past
presenceTimeoutMsmarks a device offline. This is the single most useful alert. - Battery. A device that is not charging is a device that will stop.
- Signal. Sustained low signal predicts send failures before they happen.
- Queue depth. A growing outbox means sends are being accepted faster than the radio drains them.