Raspberry Pi reliability is rarely limited by the board itself; it is limited by the SD card, the power supply, heat and software that nobody restarts when it hangs. This guide walks through the changes that turn a Pi from a desk project into an MQTT gateway that runs unattended for months: reducing storage writes, using a read-only root filesystem, choosing power and cooling, enabling watchdogs and monitoring the device remotely over MQTT. Each section includes the commands to apply it.
Why Always-On Pis Fail
When a Pi gateway goes quiet in the field, the cause usually falls into one of a few categories:
| Failure | Typical symptom | Root cause |
|---|---|---|
| Storage corruption | Boots to emergency shell, read-only remount, missing files | SD card worn out or power lost mid-write |
| Undervoltage | Random reboots, USB devices dropping, Wi-Fi resets | Weak supply, long or thin cable, power-hungry peripherals |
| Overheating | Slowdowns, throttling, erratic behaviour | No cooling in a closed enclosure |
| Software hang | Device pings but data stops | Script stuck, deadlock, memory leak, network stack issue |
| Network loss | Data gap, then backlog lost | Wi-Fi drop, router reboot, cellular outage |
The good news is that every one of these has a well-known mitigation. None require exotic hardware, and most are a few lines of configuration.
Storage: Reduce Writes or Change the Medium
SD cards have limited write endurance and weak protection against power loss. A gateway that logs verbosely, writes a database and lets journald persist logs can wear through a cheap card surprisingly quickly. There are three complementary fixes.
Use better storage. A Raspberry Pi 4 or 5 can boot from a USB SSD, and the Pi 5 also supports NVMe drives through the M.2 HAT+. Both handle writes far better than SD cards. If you must use SD, choose a reputable high-endurance card designed for continuous recording.
Cut unnecessary writes. Keep logs in RAM, disable swap if you do not need it and mount with noatime:
# journald in RAM only (logs are lost on reboot, so forward important ones)
sudo mkdir -p /etc/systemd/journald.conf.d
printf "[Journal]\nStorage=volatile\nRuntimeMaxUse=30M\n" | sudo tee /etc/systemd/journald.conf.d/volatile.conf
sudo systemctl restart systemd-journald
# disable the swap file
sudo systemctl disable --now dphys-swapfile 2>/dev/null || true
# check the root mount options include noatime
findmnt /
Write deliberately. If your gateway buffers messages on disk while offline, batch the writes and use SQLite in WAL mode, as in the offline MQTT buffer in Python tutorial. Avoid rewriting a JSON state file every second.
Read-Only Root Filesystem
For gateways that do not need to change their software often, a read-only root is the strongest protection against corruption. Raspberry Pi OS includes an overlay filesystem option: the real root stays read-only and all changes go to a RAM layer that disappears on reboot.
sudo raspi-config nonint enable_overlayfs
sudo reboot
# later, to update software:
sudo raspi-config nonint disable_overlayfs
sudo reboot
You can also enable it interactively under Performance Options in raspi-config. Plan for two consequences. First, anything the gateway must keep (configuration changes, a message buffer) needs a separate writable partition or external drive. Second, updates require a maintenance reboot cycle, so automate or document it.
Power: The Most Underrated Factor
Undervoltage causes more mysterious behaviour than any other hardware issue. Use the official power supply for your model, or an industrial supply with headroom: the Raspberry Pi 5 is designed for a 5 V 5 A USB-C supply, and the Pi 4 for 5.1 V 3 A. Keep cables short and thick, and power USB drives or modems from a powered hub if they draw a lot.
Check whether the Pi has ever seen undervoltage or throttling since boot:
vcgencmd get_throttled
A result of throttled=0x0 is what you want. Bit 0 (0x1) means undervoltage right now, bit 16 (0x10000) means undervoltage has occurred since boot, and bits 2 and 18 report throttling. Publish this value over MQTT so you can see problems before they cause failures.
For sites with unreliable mains, a small UPS HAT or a DC UPS gives the Pi time to shut down cleanly. Even a few seconds of hold-up time protects the filesystem far better than a hard cut.
Heat and Enclosures
The Pi throttles its CPU when it gets hot, which protects the hardware but slows your application. In a sealed plastic box in the sun, a Pi can reach that point with little load. Use a heatsink case or the official Active Cooler on a Pi 5, ventilate enclosures and keep the Pi away from other heat sources. Read the temperature with vcgencmd measure_temp and include it in your health messages.
Watchdogs: Recover Without a Site Visit
A watchdog restarts the system when software stops responding. Use two layers.
Hardware watchdog via systemd. The Pi's SoC includes a watchdog timer that systemd can feed. If the kernel or systemd itself hangs, the board reboots.
sudo mkdir -p /etc/systemd/system.conf.d
printf "[Manager]\nRuntimeWatchdogSec=15\nRebootWatchdogSec=2min\n" | sudo tee /etc/systemd/system.conf.d/watchdog.conf
sudo systemctl daemon-reexec
dmesg | grep -i watchdog
Application watchdog. A hung Python process does not trigger the hardware watchdog because systemd is still healthy. Run the gateway as a systemd service with Restart=always, and for hangs (not just crashes) use Type=notify with WatchdogSec=: the script must send a heartbeat regularly or systemd kills and restarts it.
import os
import socket
def sd_notify(state: str):
addr = os.getenv("NOTIFY_SOCKET")
if not addr:
return
if addr.startswith("@"):
addr = "\0" + addr[1:]
with socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) as s:
s.connect(addr)
s.sendall(state.encode())
# after MQTT connects: sd_notify("READY=1")
# in the main loop, only when work is actually progressing:
# sd_notify("WATCHDOG=1")
Only send WATCHDOG=1 when the loop is genuinely healthy, for example after a successful read and publish. Sending it from a separate thread that always runs defeats the purpose. The full unit file is in the guide to running a Python MQTT script on boot.
Network Resilience
Connectivity drops are normal, not exceptional. Design for them:
- Let paho-mqtt reconnect automatically with
reconnect_delay_set(1, 60)andconnect_async(). - Buffer readings locally while disconnected and replay them in order.
- Include a timestamp in every payload so replayed data lands at the right time.
- Use a Last Will message on a retained
statustopic so the backend knows when the gateway disappears. - Prefer Ethernet over Wi-Fi where possible; on Wi-Fi, disable power saving with
sudo iw dev wlan0 set power_save offif you see drops.
Remote Health Monitoring over MQTT
You cannot fix what you cannot see. Have every gateway publish a small health message every minute: uptime, CPU temperature, throttled flags, free disk, buffer depth and software version. The Raspberry Pi system stats over MQTT tutorial shows a complete publisher. With a cloud MQTT broker in the middle, you can watch a whole fleet from one place, and ConnectMQ threshold alert rules can flag a gateway whose temperature or buffer depth crosses a limit. The retained Last Will status, plus the broker's $SYS/broker/connection/{clientId}/state topic, tells you which devices are online right now.
Reliability Checklist
- Boot from SSD or NVMe, or use a high-endurance SD card.
- Logs in RAM, swap disabled,
noatimeon the root mount. - Read-only overlay enabled for stable deployments.
- Official or industrial power supply;
get_throttledreturns0x0. - Heatsink or active cooling; temperature monitored.
- Hardware watchdog enabled in systemd.
- Gateway runs as a systemd service with
Restart=alwaysand an application watchdog. - Automatic MQTT reconnect, offline buffer and Last Will configured.
- Health metrics published every minute and watched by alerts.
- Hardened OS and TLS connections, following the secure Raspberry Pi IoT checklist.
Applied together, these steps remove the common failure modes and make the rare remaining ones recoverable remotely. For the basics of connecting a Pi to a broker in the first place, start with the Raspberry Pi MQTT tutorial, and see the official Raspberry Pi documentation for model-specific power and boot details.
Keep the Server Side Reliable with ConnectMQ
A gateway that never fails still loses data if the broker it talks to does. A fully managed MQTT service like ConnectMQ takes care of the broker so you can concentrate on the edge. Create a free Serverless broker at app.connectmq.com with no credit card, connect your gateway over TLS on port 8883 and watch its health topics in the live topic explorer.
Frequently Asked Questions
How long does an SD card last in a Raspberry Pi gateway?
It depends entirely on the write load and card quality. Reducing writes and using a high-endurance card or SSD extends life dramatically, while heavy logging can wear out a cheap card quickly.
Will a read-only filesystem break my MQTT client?
Not if the client only needs to read its code and configuration. Anything it must persist, such as an offline buffer, needs a separate writable location.
Do I need a UPS for a Raspberry Pi?
Not always, but it is worthwhile where power is unstable. A clean shutdown protects the filesystem, and a read-only root reduces the damage when power is cut without warning.
Should I schedule regular reboots?
Scheduled reboots hide problems rather than fixing them. Watchdogs plus health monitoring are better, but a weekly reboot is a pragmatic fallback while you investigate a leak.
