Troubleshooting Tip: FortiSOAR GUI inaccessibility from the SOC

If FortiSOAR is not accessible from the SOC, this should be treated as a highly critical incident. To protect business stability and ensure operational continuity, validate the following checkpoints and take corrective actions without delay.

In case of failure:

In case of success:

1. Confirm whether the access traffic is actually reaching FortiSOAR: It is possible to verify whether the incoming connection requests are arriving at FortiSOAR and being processed by reviewing ssl_cyops_api_access.log. This command can only check when a browser is not logged in to FortiSOAR. If the browser is already logged in, it is possible to use tcpdump to verify whether the traffic is reaching FortiSOAR.

sudo su

tail -n 0 -F /var/log/cyops/cyops-api/ssl_cyops_api_access.log | grep --line-buffered -iF 'GET /auth/license/?param=eula'
x.x.x.x - - [19/Dec/2025:05:50:21 +0000] "GET /auth/license/?param=eula" 200 196 "https://x.x.x.x/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36" "-"

2. If the log entry is not observed, validate DNS and routing: If no relevant log entries are observed, the request is likely not reaching FortiSOAR. Verify DNS resolution and routing paths end-to-end. Trying the IP address instead of the FQDN is a good option. 
   For remote scenarios, validate connectivity from within the corporate network (e.g., an in-office workstation or through the corporate VPN) to eliminate external-path or remote-access constraints.
   
   
3. If a load balancer exists in front of FortiSOAR, verify health checks and reset sessions: If FortiSOAR is deployed behind a load balancer, check the load balancer health check status (target/node health) and confirm that the correct backend node(s) are marked healthy. If necessary, perform a session reset/flush on the load balancer to clear stale or pinned sessions that may be contributing to the inaccessibility.