FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
This article describes the issue where the FortiGate is selected as the only member for a short time when booting up, which affects FortiGate running v7.4.7 or before.
Scope
FortiGate 7.4.7 version or before
Solution
Let's assume that the FGT-A takes the primary role due to HA override disabled and higher uptime than FGT-B. Once FGT-A reboots, FGT-B should be elected as the new primary, and FGT-A is expected to take a secondary role, because it has lower uptime.
However, FGT-A running on v7.4.7 is selected as the only member for a short time after booting up, even though the HA peer stays alive, and it turns back to the secondary role, as below.
FortiGate # diagnose sys ha history read version=1.2 HA state change time: 2025-11-11 19:55:31 message_count=18/512 <2025-11-11 19:55:31> vcluster-1: FGT-B is selected as the primary because its uptime is larger than peer member FGT-A. <2025-11-11 19:55:31> new member 'FGT-B' joins the cluster <2025-11-11 19:55:31> vcluster-1: FGT-A is selected as the primary because it's the only member in the cluster. <2025-11-11 19:55:31> hatalk started <2025-11-11 19:54:17> hatalk exited <2025-11-11 19:54:12> vcluster-1: FGT-B is selected as the primary because SET_AS_SECONDARY flag is set on peer member FGT-A. <2025-11-11 18:02:14> vcluster-1: FGT-A is selected as the primary because its uptime is larger than peer member FGT-B.
The unnecessary HA selection issue is fixed in v7.4.8, v7.6.0 or later, which includes the fix for bug ID 1000808.
