The Complete FortiGate HA Commands & Troubleshooting Guide

Managing High Availability (HA) in a Fortinet environment is critical for maintaining seamless network uptime. However, when clusters fail to sync, heartbeat links degrade, or unexpected failovers occur, knowing the exact FortiGate HA commands is your fastest route to a resolution. Whether you are dealing with a split-brain scenario, diving into MD5 checksum mismatches, or forcing a complete configuration resync, this comprehensive cheat sheet covers every essential show, get, and diagnose debug command you need to troubleshoot FortiGate HA clusters like an expert.

SECTION 1 – HA STATUS & OVERVIEW COMMANDS

Primary Status Commands — Start Here Every Time

Complete HA status — the single most useful HA command

get system ha status

The first command to run for any HA issue. Shows every critical HA parameter in one output:

HA peer information — detailed per-unit view

diagnose sys ha status

Extended version of the above. Adds:

Per-unit HA statistics

diagnose sys ha dump-by vcluster

Dumps complete HA cluster state per virtual cluster. Shows session synchronisation state, interface monitoring status, and failover history. Use in multi-VDOM environments to see HA state per VDOM.

Check HA configuration on both units

show system ha

Shows the full HA configuration block — mode, group-id, group-name, password, heartbeat interfaces, monitored interfaces, priority, override setting, session-pickup config, and synchronisation settings. Run on both units and compare output — any difference is a potential instability source.

HA uptime and failover history

diagnose sys ha history read

Shows the HA event history — every failover, unit join/leave, interface link change, and heartbeat loss event with timestamps. Essential for understanding why a failover occurred and when.

Read Also :

• FortiGate Packet Flow & IPsec Debug
• Meraki API Updating VLANs
• Learn Cisco Meraki API
• How to Get Your Organization ID and Network ID

SECTION 2 — HA HEARTBEAT & LINK MONITORING

Heartbeat Commands

Check heartbeat interface statistics

diagnose ha hb-stat

Shows heartbeat packet counters per heartbeat interface:

A rising lost counter means the heartbeat link is degraded — even before a full failover triggers.

Check heartbeat interface configuration

show system ha | grep hbdev

Shows which interfaces are configured as heartbeat devices and their priorities. HA heartbeat should run on dedicated interfaces, not shared data interfaces.

Heartbeat packet debug — raw HA protocol

diagnose debug application hatalk -1
diagnose debug enable

hatalk is the HA heartbeat and state synchronisation daemon. Shows every heartbeat exchange, state advertisement, and role negotiation message between cluster units. Use when units are not forming a cluster or are repeatedly renegotiating roles.

Check HA heartbeat interface connectivity

diagnose ha heartbeat list

Lists active heartbeat interfaces with their current link state and packet statistics. An interface showing down here means the heartbeat path is broken on that link.

Test heartbeat path with ping (from primary to secondary)

execute ha manage <secondary-index> admin

Opens a CLI session on the secondary unit from the primary. Then:

execute ping <primary-heartbeat-ip>

Tests Layer 3 reachability over the heartbeat link. If this fails, check the cable, switch, or VLAN between the two units.

Interface Monitoring Commands

Check monitored interface status

diagnose sys ha interface-stats

Shows all interfaces being monitored by HA with their current status. A monitored interface going down triggers a failover if the secondary has that interface up. Output fields:

Check which interfaces are configured for HA monitoring

show system ha | grep monitor

Shows monitor lines in HA config. Only interfaces listed here trigger failover when they go down. An interface not in this list can go down without affecting HA roles.

Interface weight in HA decision

diagnose sys ha port-stats

Shows per-port HA statistics including the weight each interface contributes to the unit’s HA score. The unit with the higher score becomes primary.

SECTION 3 — HA SYNCHRONISATION

Config Sync Commands

Check configuration synchronisation status

diagnose sys ha showcsum

The most important sync verification command. Shows MD5 checksums for every configuration domain across both cluster units. A matching checksum means configs are in sync. A mismatch means the secondary has drifted.

Output structure:

is_manage_master()=1, is_root_master()=1
debugzone
 global: checksum
 root: checksum
 sum: checksum
datazone
 global: checksum
 root: checksum
 sum: checksum

If sum values differ between primary and secondary, configs are out of sync.

Detailed checksum per configuration domain

diagnose sys ha checksum show

Shows per-object checksums broken down by configuration category — interfaces, policies, routing, VPN, users, and so on. Use this to identify which specific configuration domain is out of sync when showcsum shows a mismatch.

Checksum for a specific VDOM

diagnose sys ha checksum show <vdom-name>

Filters checksum output to a specific VDOM. In multi-VDOM environments this isolates whether a sync issue is global or VDOM-specific.

Live configuration sync debug

diagnose debug application hasync -1
diagnose debug enable

hasync is the HA configuration synchronisation daemon. Shows every config object being pushed from primary to secondary, acknowledgements, and any sync failures. Run when secondary is consistently out of sync or after a config change that didn’t replicate.

Force a full configuration re-synchronisation

execute ha synchronize start

Forces the primary to push its complete configuration to the secondary. Use after manually resolving a sync conflict or when checksums are mismatched and you want to force alignment. The secondary will apply the primary’s config in full.

Check sync queue depth

diagnose debug application hasync 4
diagnose debug enable

Level 4 shows the synchronisation queue — pending config objects waiting to be pushed to the secondary. A large queue means sync is falling behind — usually indicates a high rate of config changes or a slow heartbeat link.

Session synchronisation status

diagnose sys session-sync status

Shows the session synchronisation state — how many sessions are queued for sync, how many have been synced, and the sync rate. In active-passive mode, synced sessions survive a failover without dropping.

diagnose sys session-sync stats

Cumulative session sync statistics — total sessions synced, sync errors, and bypass count (sessions that were not synced due to age or type).

Check which session types are synced

show system ha | grep session

Shows session-pickup configuration — whether session pickup is enabled for TCP, UDP, ICMP, and expectation sessions. Sessions not enabled for pickup will drop on failover.

SECTION 4 — HA FAILOVER COMMANDS

Failover Verification

Check failover reason from event log

diagnose sys ha history read

Shows HA event log with failover reasons. Each entry includes:

Manually trigger a failover (for testing)

diagnose sys ha reset-uptime

Resets the uptime counter on the primary unit. If override is disabled, the secondary (with higher or equal uptime) may take over. Use in a maintenance window to test failover without a real fault.

execute ha failover set 1

Forces an immediate role swap — current primary becomes secondary and vice versa. Use for planned maintenance or failover testing.

execute ha failover unset 1

Clears the forced failover state and allows normal HA election to resume.

Check if override is enabled

show system ha | grep override

override enable means the unit with the highest priority always becomes primary after any negotiation — even after a failover, it will preempt back. override disable means the current primary stays primary unless it fails — more stable for production.

HA priority verification

show system ha | grep priority

Shows the configured priority on this unit. Higher priority = preferred primary. Must be different on each unit if override enable is set — identical priorities fall back to serial number comparison.

SECTION 5 — HA DEBUG COMMANDS

Core HA Debug

HA master election debug

diagnose debug application hatalk -1
diagnose debug enable

Shows the full master election process — hello messages, capability advertisements, priority comparison, and the final role decision. Use when units are repeatedly renegotiating or the wrong unit is becoming primary.

HA config sync debug

diagnose debug application hasync -1
diagnose debug enable

Shows configuration replication events — which objects are being pushed, acknowledgements, and failures. Use when checksums are mismatched or configuration changes on the primary aren’t appearing on the secondary.

HA daemon debug

diagnose debug application had -1
diagnose debug enable

had is the main HA daemon that coordinates all HA functions. Shows high-level HA events — cluster formation, role changes, interface monitoring events, and daemon restarts.

HA link monitoring debug

diagnose debug application halink -1
diagnose debug enable

Shows interface monitoring events — link state changes on monitored interfaces and the HA score recalculation triggered by each event. Use when a monitored interface going down is not triggering the expected failover.

HA session synchronisation debug

diagnose debug application hasession -1
diagnose debug enable

Shows session sync events — individual sessions being queued for sync, sync completions, and errors. Use when sessions are dropping after failover despite session-pickup being enabled.

HA firmware and version consistency check

get system status | grep Version

Run on both units. FortiOS version must be identical on both cluster members. A version mismatch after a partial upgrade causes HA instability and sync failures.

HA serial number and model verification

get system status | grep Serial
get system status | grep Model

Run on both units. Model must be identical (you cannot cluster a 60F with a 80F). Serial numbers must differ — identical serial numbers indicate a cloning issue.

Full Debug Stack — All HA Daemons Together

For complex HA issues where the failure mode is unclear, run all HA daemons simultaneously:

diagnose debug reset
diagnose debug disable
diagnose debug application hatalk -1
diagnose debug application hasync -1
diagnose debug application had -1
diagnose debug application halink -1
diagnose debug enable

This produces the complete HA event stream. Capture the output to a file — it will be verbose.

SECTION 6 — HA CHECKSUM — DEEP DIVE

Understanding and Using Checksums

Show full checksum for both units simultaneously

Run on primary:

diagnose sys ha showcsum

Then connect to secondary:

execute ha manage 1 admin
diagnose sys ha showcsum

Compare the sum: line in each output. Matching = in sync. Different = sync issue.

Detailed per-category checksum breakdown

diagnose sys ha checksum show

Full output on a healthy cluster (both units must show identical values):

global:
  system.checksum:            a1b2c3d4
  router.checksum:             e5f6g7h8
  firewall.checksum:          i9j0k1l2
  vpn.checksum:                m3n4o5p6
  user.checksum:               q7r8s9t0
  certificate.checksum:     u1v2w3x4
  log.checksum:               y5z6a7b8

root (VDOM):
  policy.checksum:             c9d0e1f2
  address.checksum:          g3h4i5j6
  service.checksum:          k7l8m9n0
  routing.checksum:         o1p2q3r4
  sum:                              s5t6u7v8

Each category corresponds to a configuration domain. When a specific category checksum differs, that tells you exactly which config area is out of sync — no need to compare the entire config manually.

Checksum after a config change — verify sync propagated

# Make a config change on primary
# Wait 10-15 seconds for sync
diagnose sys ha showcsum
execute ha manage 1 admin
diagnose sys ha showcsum
# Compare — sums should match after sync completes

Force checksum recalculation

diagnose sys ha checksum recalculate

Forces the HA daemon to recalculate all checksums from the current running config. Use when you suspect a stale checksum is showing a false mismatch.

Checksum mismatch resolution workflow

# Step 1 — identify which domain is mismatched
diagnose sys ha checksum show

# Step 2 — check if sync is still in progress
diagnose debug application hasync 4
diagnose debug enable
# Wait 30 seconds and check if checksums converge

# Step 3 — if still mismatched, force resync
execute ha synchronize start

# Step 4 — wait 60 seconds then recheck
diagnose sys ha showcsum

# Step 5 — if still mismatched, check sync errors
diagnose debug application hasync -1
diagnose debug enable
# Look for error messages in sync output

# Step 6 — last resort — reboot secondary
# Primary continues forwarding uninterrupted
execute ha manage 1 admin
execute reboot

SECTION 7 — HA SECONDARY UNIT ACCESS

Accessing the Secondary Unit CLI

Open CLI session on secondary from primary

execute ha manage <index> <admin-user>

Opens a direct CLI session on the secondary unit proxied through the primary. The <index> is the secondary unit’s position in the cluster — usually 1 for the first secondary.

Example:

execute ha manage 1 admin

You are now on the secondary CLI. All commands run here execute on the secondary unit. Type exit to return to the primary.

Find the secondary unit index

get system ha status

The secondary unit’s index number appears next to its serial number in the output. In a two-unit cluster the secondary is always index 1.

Run a command on the secondary without staying in its session

execute ha manage 1 admin "diagnose sys ha showcsum"

Some FortiOS versions allow passing a command string directly. Returns the output to your current primary session.

Check secondary unit resource usage

execute ha manage 1 admin
get system performance status

Run on the secondary to check CPU, memory, and session count. Compare with the primary — significant differences indicate load imbalance or a hardware issue on one unit.

SECTION 8 — HA SHOW & GET COMMANDS — COMPLETE LIST

Configuration commands

show system ha

Full HA configuration — mode, password, heartbeat interfaces, monitored interfaces, priority, session-pickup, and sync settings.

show system ha | grep mode

Quick check of HA mode (a-p or a-a).

show system ha | grep priority

Priority value on this unit.

show system ha | grep override

Override setting — enable means highest priority always wins.

show system ha | grep monitor

Monitored interfaces list.

show system ha | grep hbdev

Heartbeat interface(s) and their priorities.

show system ha | grep session

show system ha | grep password

Shows whether HA password is set (value is encrypted — confirms it is configured).

Status commands

get system ha status

Primary HA status overview including master selection reason and per-unit stats.

get system performance status

CPU, memory, and network usage — run on both units to compare.

get system status

FortiOS version, serial number, model — run on both units to verify hardware and software match.

get hardware nic <interface>

Physical NIC stats for a specific interface — errors, drops, speed, duplex. Use for heartbeat interface hardware diagnostics.

SECTION 9 — HA TROUBLESHOOTING SCENARIOS

Scenario 1 — Units Not Forming a Cluster

# Check both units are seeing each other
diagnose sys ha status
# Look for 'HA group formation: Forming' — means not yet paired

# Debug heartbeat messages
diagnose debug application hatalk -1
diagnose debug enable
# Look for 'hello' messages from peer — if none, heartbeat link is broken

# Verify heartbeat interface is up
diagnose ha hb-stat
# Check for non-zero 'rx' counter — if rx=0, no heartbeat received from peer

# Check HA config matches on both units
show system ha
# Group-id, group-name, password, and mode must be identical 

# Check failover history
diagnose sys ha history read
# Identify the trigger — interface down, heartbeat loss, or manual

# Check heartbeat loss counter
diagnose ha hb-stat
# Rising 'lost' counter = intermittent heartbeat link issue

# Check monitored interface stability
diagnose sys ha interface-stats
# Rising 'fail_cnt' = interface is flapping

# Check for split-brain (both units think they are primary)
get system ha status
# Run on both units — only one should show as primary

Scenario 3 — Config Not Syncing to Secondary

# Step 1 — confirm checksums differ
diagnose sys ha showcsum
# Run on both units — compare 'sum:' values

# Step 2 — identify which domain is out of sync
diagnose sys ha checksum show

# Step 3 — check sync daemon
diagnose debug application hasync -1
diagnose debug enable
# Look for sync errors or timeouts

# Step 4 — force resync
execute ha synchronize start

# Step 5 — verify after 60 seconds
diagnose sys ha showcsum

Scenario 4 — Sessions Dropping After Failover

# Check session pickup is enabled
show system ha | grep session-pickup
# Must show 'set session-pickup enable'

# Check session sync status
diagnose sys session-sync status
# Confirm sessions are being synced before failover

# Check session sync stats
diagnose sys session-sync stats
# 'sync_errors' count rising = sessions not being synced correctly

# Debug session sync
diagnose debug application hasession -1
diagnose debug enable
# Look for sync failures or capacity issues

Scenario 5 — Wrong Unit Becoming Primary

# Check priority on both units
show system ha | grep priority
# Higher value = preferred primary

# Check override setting
show system ha | grep override
# 'override enable' = highest priority always wins
# 'override disable' = current primary stays primary

# Check master selection reason
get system ha status
# 'Master selected using' field shows why current primary won

# Force correct unit to be primary
# On the unit that SHOULD be primary:
execute ha failover set 1
# Then verify
get system ha status

QUICK REFERENCE — ALL HA COMMANDS BY CATEGORY

Status & Overview

Checksum & Sync

Debug Daemons

Configuration

Failover & Maintenance

UNIVERSAL CLEANUP

diagnose debug disable
diagnose debug reset

Bhardwaj Vishnu

Bhardwaj Vishnu is a Network Security Engineer with hands-on expertise in enterprise firewall management, network automation, and multi-vendor infrastructure. He holds Fortinet NSE 4/NSE 5, a Cisco CCNA, and the full Cisco Meraki certification track. He architects FortiGate security policies, manages Cisco Meraki MX/MS/MR deployments, and handles enterprise routing and switching. Every guide on netconfig.io comes from direct production experience — real CLI commands, verified configs.