Hi  @RF_Dude 

Thanks for posting here.

Although this feature seems helpful for troubleshooting, from a practical operations and product design perspective, its significance may indeed be limited, for the following reasons:  

1. Sporadic issues are difficult to reproduce with logs
   - Most random failures (e.g., automatic device reboots, momentary power loss) are caused by random hardware or environmental factors (e.g., power fluctuations, overheating). Logs can only record that a reboot occurred but cannot directly identify the root cause.  

2. Excessive logs may obscure critical information
   - Frequently logging device startup/heartbeat status can lead to log overload, potentially burying more important failure signals (e.g., network congestion, misconfigurations).  
   - For example, in large networks, hundreds of devices reporting heartbeat logs every minute would create unnecessary noise for administrators.  

3. Existing mechanisms can already infer issues indirectly
   - Through indirect logs such as device offline time, IP reassignment records, and client disconnections, it is usually possible to deduce whether a device has rebooted—without needing dedicated boot logs.  
   - If a device frequently reboots abnormally, the issue is more likely due to hardware failure or firmware bugs, requiring replacement or updates rather than log analysis.  

4. Logs cannot be saved if the controller is offline  
   - If the entire system loses power (e.g., UPS depletion as mentioned by the user), the controller (OC200) will also shut down. In this case, even if devices generate boot logs, they **cannot be uploaded to the controller**, rendering the feature useless.  

5. More suitable for enterprise-grade monitoring tools  
   - In professional environments, network health should rely on active monitoring tools (e.g., SNMP, Prometheus) for real-time device status tracking, rather than post-mortem log analysis.