A device on a lab bench gets rebooted by a human when it misbehaves. A device in a pump house does not. Designing for that difference is most of what field reliability means.
Use the hardware watchdog properly
A watchdog that is kicked from a timer interrupt proves only that the timer is running. Kick it from the main loop, and only after confirming that the tasks that matter have completed a cycle. A watchdog that cannot detect a hung task is decoration.
Brownout is not the same as power loss
Clean power removal is easy. The dangerous case is a supply that sags to a level where the processor keeps executing but peripherals misbehave, which is where corrupted writes to flash come from. Enable the brownout detector, set it above the point where your slowest peripheral becomes unreliable, and treat a brownout reset as a first class event that gets logged.
Define the safe state before you write the logic
For every output, decide what it should do when the firmware is not in control: on reset, during a firmware update, and after a watchdog trip. In a monitoring device the answer is usually simple, since it should not be driving anything. In any device that does drive something, that answer belongs in hardware, not in a conditional.
Make storage crash-safe
Assume power will be cut mid-write, because eventually it will be. Journalled or double-buffered writes with a validity marker turn a corrupted record into a recoverable one. Never leave your only copy of a configuration in the middle of being overwritten.
Log enough to diagnose without a visit
Record the reset reason, the uptime before the reset and the last few state transitions. This costs almost nothing and is often the difference between a fix and a guess when the device is a long way away.