Hey folks — has anyone else noticed their Firebox hitting a weird uptime limit? I’ve had this happen on two different models now (an M270 and an M370). Both were humming along just fine, then right around the 200-day mark, they rebooted on their own. No alerts, no warnings in the logs that pointed to a crash.
Here’s what I checked so far:
- Power: Clean UPS, no outages reported.
- Logs: Just a standard startup sequence after the reboot, no panic or temperature warnings.
- Policies/Config: No scheduled reboots, and both boxes are on the latest recommended firmware.
It feels almost like a built-in safety reset, but I haven’t found any setting or documentation about it. I’m curious if others have seen this pattern.
A couple questions for the room:
- Are you running into similar uptime-triggered reboots?
- If so, what model and firmware version?
- Any workarounds or official WatchGuard guidance you’ve come across?
I love the hardware generally, but unexplained reboots make me nervous for stability. Might set up a monitoring alert to reboot manually at 180 days just to be safe, but I’d rather understand the root cause.
✌️
✌️
Interesting. I've run a few M370s in colo setups and haven't hit the 200-day mark with them yet, but now I'm going to check my monitoring.
Your log findings line up with what I'd expect from a watchdog or health check reset - it's clean, which makes it look intentional rather than a crash. I haven't seen official guidance either, but the pattern is too specific to be coincidence. A scheduled manual reboot at 180 days is probably a smart stopgap, though it feels like working around a firmware bug.
Could you share the exact firmware build numbers from those boxes? I'm wondering if it's tied to a particular maintenance release train.
Extract, transform, trust
Good point about the firmware build numbers. That detail could help spot a pattern if others start reporting in.
I've always treated WatchGuard's release notes as fairly thorough, so if this is a watchdog timer, it feels like something they'd document. The lack of any mention there makes me lean towards an unintended side effect, maybe from a memory management routine. It's a tricky one to diagnose without more internal logs.
—HR
That's a solid point about the release notes. At our shop we've found them reliable for known issues too.
It makes me wonder if this could be related to some internal counter or log rotation hitting a threshold silently. I've seen similar behavior on older Linux systems where a service would restart after a certain uptime, but it wasn't documented as a feature.
Have you ever seen an undocumented "feature" like that in other network gear?
Undocumented uptime resets? Absolutely. Seen it on old Cisco ASAs that would quietly restart IPSec processes around 11 months, and some early FortiGate models had a memory fragmentation routine that triggered a reboot just shy of a year. It was always some internal timer or counter rolling over.
> some internal counter or log rotation hitting a threshold silently
You're on the right track. It's rarely the main logs. Check if there are any circular debug buffers or SNMP uptime counters that could wrap. On one platform, the culprit was a signed 32-bit integer tracking milliseconds - guess what happens after roughly 24 days?
The pattern is too neat for a memory leak. That usually causes instability before a hard reset. This smells like a planned, silent watchdog "feature" someone thought was a good idea for system health, but forgot to document or make configurable.