Sophos Firewall restarts unexpectedly: Check the cause

If a Sophos Firewall restarts without a planned intervention, do not immediately reboot it again or restart services as a precaution. First determine whether the entire appliance actually restarted or whether only WebAdmin, an individual service, or the active HA role failed. A successful restart may restore operation, but it does not explain the cause.

⚠️ Preserve evidence before making further changes: Do not delete logs, provoke another reboot, change the status of auto-reboot-on-hang, or start debug, service actions, fsck, Factory Reset, or Reimage on suspicion. Such actions can alter evidence, cause new interruptions, or obscure the actual fault.

The safe quick path is:

Record the time with time zone, outage duration, and last known working observation.
Record whether traffic, WebAdmin, SSH, and the local console were affected at the same time.
In the Control Center, preserve the uptime, services, interfaces, VPNs, and, for HA, the cluster status.
Under Log viewer > System, export relevant events and preserve the history under Diagnostics > System graphs.
Under Diagnostics > Tools, download a CTR as well as sysinit.log, syslog.log, and, for HA, the local node logs.
In the Device Console, read the uptime, build, and auto-reboot status:

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

For HA, compare the roles, status, Last status change, and uptime of both nodes.
Only then investigate the appropriate cause branch and fully test production operation.

system auto-reboot-on-hang show does not change anything. SFOS enables this function by default and can restart the firewall automatically if the kernel stops responding. However, a displayed enable proves only the configured recovery policy, not that a kernel hang caused this particular restart.

Check what actually failed

The observed interruption alone does not yet prove a complete reboot. These four cases require different next steps:

Complete appliance reboot: The uptime starts again, several services and connections were interrupted at the same time, and SFOS ran through the system startup again. The reboot triage in this article now applies.
Only WebAdmin or one service was affected: The uptime continues and production traffic may keep working partly unchanged. In that case, a targeted restart of the WebAdmin GUI or check of an individual service is more appropriate than an appliance reboot.
HA failover: Users may notice a brief interruption even though only the roles changed. The uptime, role, and logs of each node show whether a device actually rebooted. The HA check follows below.
Failsafe mode: The firewall does not start normally and shows a recovery state on the console. In that case, show failure-reason from the Sophos Firewall failsafe mode runbook is the correct first command.

The uptime is therefore strong evidence for the restart period, but not proof of the cause. A brief power interruption, a kernel hang, a firmware fault, and a planned administrator restart all reset it.

Preserve evidence after the restart

After an unplanned reboot, volatile data may already be missing. Nevertheless, preserve the reachable state completely before making further changes.

The incident record should include at least:

model, serial number, and platform: hardware, VM, or cloud
complete SFOS version with MR and build
exact time, time zone, outage duration, and frequency
affected functions: traffic, WebAdmin, SSH, console, VPN, and published services
most recent firmware, configuration, hypervisor, storage, or power change
current uptime and status of services, interfaces, VPN, and HA
for HA: affected node, roles before and after the event, and peer status
available UPS, PDU, hypervisor, cloud, switch, and monitoring events from the same time window

Under Diagnostics > System graphs, check CPU, Memory, Load, and Disk around the suspected time. An anomaly can narrow the search. A normal current value, however, does not prove that the load before the reboot was also normal.

Under Log viewer > System, filter and export startup, restart, shutdown, and HA events for the same time window. The Log Viewer is a useful time source, but not complete proof of a crash. Events that had not yet been saved may be missing after a hang.

Read the system state in the Device Console

In addition to uptime and build, these read-only commands show the current state:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

Record the values together with the query time in the incident notes. They describe the state after the restart and must not be interpreted retrospectively as its cause.

Check startup and system logs

In the Advanced Shell, the most important files can be read completely and without modification:

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

Press q to exit less. Within the file, /search-term starts a search, for example /error; press n to move to the next match.

sysinit.log documents the system startup.
syslog.log contains kernel and system events.
applog.log and csc.log help classify internal actions and changes close to the event.

Under Diagnostics > Tools > Troubleshooting logs, download the same files as well so that the original data is preserved outside the appliance. The Sophos Firewall service log mapping explains which additional log file belongs to a service.

Additionally, under Diagnostics > Tools > Consolidated troubleshooting report, generate a CTR with System snapshot and All log files. The CTR contains the current system state and many logs in an encrypted archive. Service subsystem logs contain no more than 10'000 lines by default; complete individual logs remain important for longer periods. The full procedure is described in Preserve Sophos Firewall logs for support.

An empty log section does not rule out a crash or power interruption. Information that had not yet been written to disk may be lost during a hang, and local logs can rotate. External time sources and a precise incident timeline are therefore important.

Distinguish HA failover from a node reboot

Under System services > High availability, preserve Health, Mode, roles, status, serial numbers, and Last status change. In the Device Console, also run:

system ha show details

Then check the uptime on both nodes. If only one node has a short uptime, this indicates a restart of that device. If the uptimes are unchanged but the roles switched, first investigate the HA trigger, such as a Monitored Port or peer problem. A manual switch of the active role can also restart the former Primary, so a possible administrator action belongs in the timeline as well.

The HA logs are stored locally on each node and are not synchronized. At least these files are therefore relevant on both appliances:

cd /log
less ha.log
less msync.log

ha.log shows cluster formation and status changes, while msync.log shows synchronization. Do not initiate a simultaneous restart of both nodes or force another failover to reproduce the problem. The complete role and link diagnostics are described in Sophos Firewall High Availability.

Narrow down the cause from the context

Planned administrator or firmware restart

First compare the change calendar, maintenance windows, administrator actions, Sophos Central tasks, and notifications with the event time. Preceding configuration changes can be classified using the Audit Trail logs. Sophos Firewall creates system events for a startup and for restart or shutdown through WebAdmin. If email notifications are configured, the message in the mailbox can also confirm the time and the sending firewall.

If the restart occurred during a firmware or hotfix process, preserve the source version, target version, build, update time, and fwmgmt.log. A restart is part of a normal firmware change; several unplanned reboots or an unexpected build are not. Continue with Perform a Sophos Firewall firmware update.

Kernel hang or software fault

With auto-reboot-on-hang enabled, SFOS can restart automatically after the kernel stops responding. The function improves availability but does not leave unambiguous local proof of the cause in every case. Document the displayed status and do not change it during triage. Narrow down the case using the time, logs, System graphs, CTR, and exact build.

In SFOS 22.0 MR2 Build 546, Sophos fixed several independent crash and restart cases, including:

NC-180974: kernel crash in sdwan_profile with HA failover
NC-178354: kernel crash when matching SD-WAN rules
NC-178745: automatic restart of an HA device because of out-of-memory
NC-180433: repeated crash with multicast traffic through a VPN tunnel

These issue IDs show why The firewall rebooted is not yet a diagnosis. Only if the build, function, traffic, and error time match the documented case should the supported upgrade path to MR2 Build 546 or a newer approved version be checked. If the error recurs on this or a newer build, do not continue to assign it automatically to the same old issue ID. The remaining fixes are classified in the SFOS 22.0 MR2 overview.

Do not intentionally reproduce a kernel crash through load tests, multicast, SD-WAN changes, or a forced failover. Document the configuration and traffic patterns and then evaluate them with Sophos Support.

Load, storage space, or storage

The CPU, Memory, Load, and Disk history can show whether a persistent anomaly was already present before the reboot. Sophos also specifies /log/system-monitor/cpu_trigger.log for automatically captured system states during high CPU utilization. The SFOS 22 documentation adds /log/system-monitor/memory_trigger.log for high memory utilization; do not assume that this file exists on SFOS 21.5.

A full disk, heavy I/O load, and an SSD fault are different problems. Do not delete reports or logs on suspicion. Use Check Sophos Firewall storage space and reports for the read-only check and intended cleanup; Check Sophos Firewall SSD health using SMART explains the hardware condition of the storage device.

Power, temperature, or hardware

On a physical XGS, check the power feed, power supplies, UPS/PDU, rack temperature, airflow, fans, LEDs, SSD, and the local console. The absence of a clean shutdown trail may fit an abrupt power event but does not prove one. The combined timeline from the firewall, UPS/PDU, monitoring, and environment is decisive.

A current temperature after the reboot is also only a point-in-time value. Checking temperature, fans, and xgs-healthmond.log explains the thermal cause branch. Recurring boot, I/O, power supply, NPU, or fan faults belong with the preserved data in the preparation of a hardware and RMA case.

Virtual firewall or cloud appliance

For a VM, additionally check hypervisor events, host restarts, datastore latency, snapshot or backup jobs, vCPU, RAM, disks, and vNICs at the same time. For AWS or Azure, include platform events, instance status, and planned maintenance in the incident timeline.

A host or platform event can restart the VM without SFOS itself causing it. Conversely, an unremarkable hypervisor does not prove a fault-free guest. Evaluate both timelines together. Sophos Firewall as hardware, VM, or cloud appliance explains the current platform and resource differences.

Check operation after the restart

A reachable login page is not yet a complete acceptance test. After preserving the evidence, check the following as appropriate for the environment:

Control Center without new service, interface, VPN, or performance warnings; additionally check System graphs and Notifications for Memory and Disk anomalies
WAN, routing, DNS, and internet access over the expected path
important site-to-site and remote-access VPN connections
central DNAT, WAF, or server publications
DHCP, RED, and Wireless if the firewall provides these services
for HA: Health, roles, synchronization, and uptime of both nodes
new system, kernel, or hardware faults since startup

Deliberately test the most important real business flows and document the time. If the uptime remains stable, this shows only that no further reboot occurred. The original cause is only considered identified when the timeline, logs, and platform observations provide a reliable explanation.

Prepare a support case and future detection

A Sophos support ticket is appropriate if the reboot remains unexplained, recurs, caused an HA or site outage, or there are indications involving the kernel, memory, storage, NPU, or hardware. Include the incident time with time zone, platform, complete build, uptime, affected functions, most recent changes, HA roles, CTR, complete relevant logs, and the external power or hypervisor timeline in the case.

Prepared monitoring improves the evidence for the next incident:

Have email notifications delivered for System started, Restart/Shutdown, and HA status changes.
Send system and HA events to Syslog or SIEM so that the timeline is preserved outside the firewall.
Monitor uptime and hardware condition through SNMP monitoring.
Operate UPS/PDU, hypervisor, and cloud alerts with the same time server and a clear site assignment.

This makes it easier to determine during the next event whether SFOS itself, an individual node, the platform, or the power and hardware environment caused the outage.