Check the Sophos Fusion Firewall Task Queue

If a change from Sophos Fusion (formerly Sophos Central) does not reach the firewall, first open:

My Products > Firewall Management > Tasks Queue

This page has two separate views: Task Queue for firewall group policies and Firewall Task Queue for MDR and API operations. A successful task confirms that the operation was processed, but not that it had the intended effect on the firewall. Queue review and local validation therefore belong together.

If the task comes from a shared group policy, Use Sophos Fusion Firewall Groups safely also explains Full Sync, Skip full sync, subgroups, and rollback preparation. Validate automatically generated site connections using Set up and verify a Sophos Fusion SD-WAN connection group.

Check a failed task safely

Open the appropriate tab and expand the task.
Record the task number, group or firewall, Status, Modified by, Entity, Sub-entity, Time, and the visible error message.
Establish whether this is a group policy or an MDR/API operation. The available actions differ.
For a group policy, check group membership and Sync & Management under My Products > Firewall Management > Firewalls.
For an MDR/API task, map the Credential ID, Entity, and Action to the initiating system or API client.
On the firewall, determine whether the change is absent, complete, or only partially present.
Decide on Retry, Skip, a corrective change, or a support case only after identifying the cause.
Validate the technical effect with a defined positive test and, where safe, a negative test.

This workflow separates two questions: Did Sophos Fusion process the operation, and does the change actually work on the firewall?

Distinguish Task Queue from Firewall Task Queue

Task Queue for group policies

Sophos Fusion automatically creates a task when an administrator changes a firewall group policy. The view shows Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity, and Time. The overall status includes the number of firewalls on which the policy was applied successfully. Expand the task to see each target firewall.

Initially, the timestamp shows when the policy was created or updated, not necessarily when distribution began. It is updated while the policy is applied and finally shows when the last firewall received it. Show History displays completed or skipped tasks for firewalls or groups that have since been deleted.

Sophos Fusion deletes tasks that remain Pending for three weeks. Preserve the task number, error, target firewalls, and time early if escalation may be required.

Firewall Task Queue for MDR and API operations

Firewall Task Queue shows MDR Settings and MDR IOCs initiated through the Firewall Configuration API. The overview groups them under Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful, and Successful.

An expanded task shows the firewall, status, Credential ID under Modified by, entity, action, and time. Sophos lists Add, Update, and Delete as example actions. The Credential ID identifies the API credentials used for the operation; it is not an administrator display like the one for a group policy.

Individual status values are Pending, In Progress, Success, Failed, and Partial Success. Partial Success means that only part of the operation was applied. Sophos gives the example of three MDR threat feed indicators where two succeeded and one failed. Do not record this as an overall success: document successful and failed items or firewalls separately and compare the local state.

For MDR IOC operations, the audit_ID links the Sophos Fusion task to the analyst action and the local Active Threat Response log. See Enable and verify MDR threat feeds on Sophos Firewall for complete validation.

Firmware upgrades are instead scheduled and monitored under My Products > Firewall Management > Firewalls. They are not part of the two queue views described here.

Bound Retry, Skip, and Force sync

The current Sophos Fusion Tasks Queue help documents Retry and Skip for failed group policy tasks. It does not document equivalent actions for Firewall Task Queue.

Retry: Use only after correcting the visible cause and confirming that the same group change is still wanted. Then check the new status per firewall and validate locally again.
Skip: Use only when you know which group change will be omitted. Skip does not replace local inspection or a later corrective change.
Wait: For Pending or In Progress while processing is plausibly progressing and no error is shown. Preserve evidence before the three-week deletion limit.
Support case: When the failure remains reproducible, affects several production firewalls, or the visible message does not permit a safe correction.

⚠️ Do not skip a task merely to make the queue look clear. The omitted change remains unresolved and must be explicitly accepted, corrected, or implemented separately.

The queue help documents no Cancel or Rollback action. Skip does not revert a distributed group change, nor does removing a firewall from its group. To return to a previous state, deliberately correct the group policy, follow the resulting task, and locally validate the previously defined target state again.

Force sync is not a retry either. If a firewall was added with Skip full sync, its local configuration may differ from the group policy. Under My Products > Firewall Management > Firewalls, open its status in Sync & Management; Force sync then applies all group configurations. Know the differences and intended target state first. For an HA pair, the link is available only for the active firewall.

Narrow down common symptoms

Group policy remains Pending

First check whether the task timestamp is still changing and which firewalls are missing from the expanded task. Then check group membership and Sync & Management under My Products > Firewall Management > Firewalls. On the affected firewall, System > Sophos Fusion must show the management status Managed. If the operation makes no progress, preserve the evidence before automatic deletion and escalate with the task number, time, and affected firewalls.

For older SFOS 22.0 installations, also check the firmware version. NC-181175 in the official SFOS 22.0 release notes describes a group policy push that remained Pending in Sophos Fusion and was not applied. Sophos lists it among the issues resolved in SFOS 22.0 MR2 Build 546. This entry does not explain every pending task, so check status and target firewalls first.

Group policy fails

Expand the task and record the affected firewall, Entity, and Sub-entity. Do not queue several changes at once. If the cause can be corrected, use Retry for that failed group policy task and then validate locally. If omitting the change is explicitly accepted, document Skip; otherwise escalate with the error message.

Firewall Task Queue shows Partial Success or Failed

Record the Credential ID, Entity, Action, time, and results per firewall or item. The Sophos Fusion help documents no Retry, Skip, or Cancel workflow for this queue. Do not transfer controls from the group policy queue: investigate the operation in the initiating MDR/API process and inspect the local current state before making another change.

Sophos Fusion saves but no task appears

First confirm that you changed and saved an actual group policy through Manage Policy. Direct changes to an individual firewall opened through Sophos Fusion do not create the same group policy task. Then check the correct tab, group, and Show History. If the expected entry remains absent, preserve the UTC time, group and firewall names, changed Entity, and Sophos Fusion administrator for Sophos Support. Retry and Skip are unavailable without a queue entry.

If the behavior is reproducible, repeat the save operation exactly once while recording a browser HAR and correlate its UTC time with /log/fwcm-updaterd.log. HAR files can contain session tokens and other sensitive data, so inspect and sanitize them before sharing. Include the HAR, log extract, time, and affected names in a Sophos support case; repeatedly cloning or deleting policy objects is not a reliable standard fix.

XGS 88/w: Local TLS exclusion list

A Sophos entry for NC-177522, since removed from the current Known Issues List, documented that editing the Local TLS exclusion list during Sophos Fusion policy synchronization could fail with Failed to apply a policy on XGS 88/w running SFOS 21.5 MR2 Build 323 or 22.0 GA Build 411. It identified a URL group that could not be updated and allowed the failed task to be skipped so subsequent tasks could proceed.

The official fix information at the time was contradictory: Fix versions listed SFOS 22.0 MR1 Build 490, while the workaround still announced a fix in the next maintenance release. Because the current list no longer contains NC-177522, do not infer another fix version. For this exact model, build, and error pattern, preserve evidence first, understand the effect of Skip, and inspect the local TLS exclusion list and related policies; confirm the current fix status with Sophos Support.

Validate the change locally

For firewall and NAT rules, Top and Bottom control only the order within the Sophos Fusion policy. Sophos Fusion places these rules at the top of the local rule list. Local rules can therefore make the effective evaluation harder to predict; Sophos recommends creating rules consistently through Sophos Fusion on centrally managed firewalls.

After a successful or corrected task, do not accept a generic “sync successful” result. Check the exact changed function on the target firewall:

Is the changed rule, policy, list, or object visible in the relevant SFOS menu?
For supported objects, does Configuration Audit show the expected change? Audit evidence does not replace a functional test.
Does defined test traffic match the expected Firewall Rule ID and, for NAT, the expected NAT Rule ID?
For web or TLS changes, do the test client, destination domain, and Web and SSL/TLS Inspection logs agree?
For VPN or other changes, does the specific use case work with the expected user and object assignments?
For MDR/API tasks, are the expected entities or indicators present locally, and does the log event match the operation?

For traffic changes, Test firewall rules with Log Viewer, Policy Test, and Packet Capture provides the local validation workflow. For extensive changes, Sophos Firewall Config Studio can also compare the intended and actual configurations. If the relevant log is unclear, see Sophos Firewall troubleshooting: services and logs.

For the change record, retain at least the task number and status, target firewall, local intended/actual comparison, test result, and log or audit evidence. Only then is the Sophos Fusion change accepted.