| This article focuses on understanding the log flow in 'diagnose sys ha history read' when an HA cluster upgrades. The following example logs are from devices that were primary and secondary before the upgrade: Primary: <2026-01-25 15:55:57> vcluster-1: FG22E1Txxxxxxxxx is selected as the primary because EXE_FAIL_OVER flag is set on peer member FG22E1Tyyyyyyyyy.
<2026-01-25 02:08:12> vcluster-1: FG22E1Tyyyyyyyyy is selected as the primary because its uptime is larger than peer member FG22E1Txxxxxxxxx.
<2026-01-25 02:08:12> new member 'FG22E1Tyyyyyyyyy' joins the cluster
<2026-01-25 02:08:11> hatalk started
<2026-01-25 02:01:49> hatalk exited
<2026-01-25 02:01:41> vcluster-1: FG22E1Tyyyyyyyyy is selected as the primary because UPGRADE_SECONDARY flag is set on peer member FG22E1Txxxxxxxxx.
<2026-01-25 02:01:20> vcluster-1: FG22E1Txxxxxxxxx is selected as the primary because UPGRADE_PRIMARY flag is unset on peer member FG22E1Tyyyyyyyyy.
<2026-01-25 02:01:20> new member 'FG22E1Tyyyyyyyyy' joins the cluster
<2026-01-25 02:01:13> port port12 link status changed: 0->1
<2026-01-25 02:01:12> hbdev port11 link status changed: 0->1
<2026-01-25 02:01:12> port port11 link status changed: 0->1
<2026-01-25 02:01:10> port port12 link status changed: 1->0
<2026-01-25 02:01:09> hbdev port11 link status changed: 1->0
<2026-01-25 02:01:09> port port11 link status changed: 1->0
<2026-01-25 01:59:59> hbdev port11 link status changed: 0->1
<2026-01-25 01:59:59> port port11 link status changed: 0->1
<2026-01-25 01:59:58> port port12 link status changed: 0->1
<2026-01-25 01:56:46> hbdev port11 link status changed: 1->0
<2026-01-25 01:56:46> port port11 link status changed: 1->0
<2026-01-25 01:56:45> port port12 link status changed: 1->0
<2026-01-25 01:56:42> vcluster-1: FG22E1Txxxxxxxxx is selected as the primary because it's the only member in the cluster.
<2026-01-25 01:56:42> heartbeats from FG22E1Tyyyyyyyyy are lost on all hbdev Secondary: <2026-01-25 15:55:56> vcluster-1: FG22E1Txxxxxxxxx is selected as the primary because EXE_FAIL_OVER flag is set on peer member FG22E1Tyyyyyyyyy.
<2026-01-25 15:55:56> Local FGT's failover is set
<2026-01-25 02:06:47> vcluster-1: FG22E1Tyyyyyyyyy is selected as the primary because its uptime is larger than peer member FG22E1Txxxxxxxxx.
<2026-01-25 02:06:47> new member 'FG22E1Txxxxxxxxx' joins the cluster
<2026-01-25 02:06:38> port port12 link status changed: 0->1
<2026-01-25 02:06:37> hbdev port11 link status changed: 0->1
<2026-01-25 02:06:37> port port11 link status changed: 0->1
<2026-01-25 02:06:36> port port12 link status changed: 1->0
<2026-01-25 02:06:35> hbdev port11 link status changed: 1->0
<2026-01-25 02:06:35> port port11 link status changed: 1->0
<2026-01-25 02:05:25> hbdev port11 link status changed: 0->1
<2026-01-25 02:05:25> port port12 link status changed: 0->1
<2026-01-25 02:05:25> port port11 link status changed: 0->1
<2026-01-25 02:01:53> hbdev port11 link status changed: 1->0
<2026-01-25 02:01:53> port port12 link status changed: 1->0
<2026-01-25 02:01:53> port port11 link status changed: 1->0
<2026-01-25 02:01:50> vcluster-1: FG22E1Tyyyyyyyyy is selected as the primary because it's the only member in the cluster.
<2026-01-25 02:01:50> heartbeats from FG22E1Txxxxxxxxx are lost on all hbdev
<2026-01-25 02:01:50> member FG22E1Txxxxxxxxx lost heartbeat on hbdev port11
<2026-01-25 02:01:41> vcluster-1: FG22E1Tyyyyyyyyy is selected as the primary because UPGRADE_SECONDARY flag is set on peer member FG22E1Txxxxxxxxx.
<2026-01-25 02:01:20> vcluster-1: FG22E1Txxxxxxxxx is selected as the primary because UPGRADE_PRIMARY flag is unset on peer member FG22E1Tyyyyyyyyy.
<2026-01-25 02:01:20> new member 'FG22E1Txxxxxxxxx' joins the cluster
<2026-01-25 02:01:19> hatalk started
<2026-01-25 01:56:42> hatalk exited 2026-01-29 01:56:42: At this time stamp, the FW02 primary firewall stops getting heartbeats from the secondary FW01 firewall since, at the same time, the secondary firewall exits the HA cluster communication as it is undergoing the upgrade and reboot process. 2026-01-29 01:56:42: After re-election, FG22E1Txxxxxxxxx (FW02) is selected as the primary unit because it is the only firewall in the HA cluster. 2026-01-29 02:01:19: The FW01 devices rejoin the HA communication after a reboot. 2026-01-29 02:01:20: The FW02 and FW01 detect each other in the HA cluster. Next, the FW02 is selected as the primary unit because the UPGRADE_PRIMARY flag is still set on FW02 and not on FW01. 2026-01-29 02:01:41: FW01 is elected as the primary once UPGRADE_SECONDARY flag is set on FW02. 2026-01-29 02:01:50: Now, FW02 has to undergo the upgrade and reboot process; as a result, it exits the HA communication. The heartbeats from FW02 are lost on FW01. After re-election, FW01 is selected as the new primary device, as it is the only member in the cluster. Once the upgrade is completed on FW02 and it rejoins the HA communication, both devices detect each other in the cluster. 2026-01-29 02:06:47: After re-election in the cluster, the FW01 was selected as the primary device due to a higher uptime. Once both devices in the cluster complete the upgrade process, the member selected as the primary device in the cluster will depend on the HA primary unit selection criteria. Related document: Technical Tip: FortiGate HA Primary unit selection process when override is disabled vs enabled | 
