Fortinet FortiGate 60F stack member missing: Diagnose & Fix
By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30
| Vendor | Fortinet |
|---|---|
| Operating system | FortiOS |
| Category | Hardware Failure |
| Skill level | Intermediate to advanced |
| DIY-able? | Yes with CLI access; some scenarios need Fortinet TAC + RMA. |
Treat this like a flight checklist. `get system status` and `diagnose hardware deviceinfo` on FortiOS returns the data you need for a Fortinet Fortinet TAC case. if you have that saved before the box dies completely, your support call is 20 minutes shorter.
I have seen FortiGate as SD-WAN router units that looked dead at the LED panel but were actually fine, the front panel had failed, not the data plane. Always verify with CLI before declaring time of death.
What follows is the recovery playbook, not the marketing version. Some steps assume a spare unit or a console cable; if you do not have them, the diagnostic section is still useful for the Fortinet TAC case.
What this guide covers
Diagnose and recover from stack member missing on a Fortinet FortiGate 60F.
Step-by-step
- Run the stack / chassis status command to see member states.
- Inspect the stack cables: re-seat both ends.
- Try replacing one stack cable at a time to identify a bad cable.
- Power-cycle the affected member if cables are good.
- If the member still doesn't rejoin, RMA it.
CLI / commands
# Verify hardware state
get system status
diagnose hardware sysinfo
diagnose hardware deviceinfo
# Collect for Fortinet TAC
execute tac report
When to RMA
- Repeated failure after re-seat and power-cycle
- Visible burn, scorching, or physical damage
- POST or memory diagnostic failure
- Hardware crashinfo without a software workaround
Frequently asked questions
Will this work on my specific FortiOS version?
The procedure reflects current FortiOS behaviour. Older releases may need minor syntax adjustments, use the CLI help (? or tab-completion) to verify.
Should I open a Fortinet TAC case immediately?
Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.
Where can I find the Fortinet official documentation?
https://community.fortinet.com/. search the product family + feature name.
Is this procedure safe in production?
Test in a lab or maintenance window first. Capture pre-change state so you can roll back.
Related guides
- All Fortinet fix guides → /fortinet/
- All vendor guides → /vendors/
Related fixes
Related guides worth a look while you sort this one out:
- Fortinet FortiGate 100F stack member missing: Diagnose & Fix
- Fortinet FortiGate 70F stack member missing: Diagnose & Fix
- Fortinet FortiGate 80F stack member missing: Diagnose & Fix
- Fortinet FortiGate as SD-WAN router stack member missing: Diagnose & Fix
- Fortinet FortiAP 231F stack member missing: Diagnose & Fix
- Fortinet FortiAP 23JF stack member missing: Diagnose & Fix
References
- Fortinet support portal: https://support.fortinet.com
- Fortinet knowledge base: https://community.fortinet.com/
- Fortinet security advisories: https://www.fortiguard.com/psirt
- Open a case: https://support.fortinet.com/Information/MyAccount.aspx
Reference material, not professional advice. Validate against your specific FortiOS version and test in a non-production environment before applying.
What changed recently?
Fault diagnosis on a Fortinet device goes faster when you map the symptom to a recent change:
- Did firmware update in the last 7 days?
- Did the network (router, ISP, VPN) change?
- Was the device moved physically?
- Did paired devices (phone, hub, app) update?
- Were any accessories swapped in or out?
The answer narrows the root cause to a manageable subset.
Safety + preconditions
Before any work on a Fortinet device:
- Unplug from mains for any internal-access procedure.
- Discharge stored energy (capacitors in PSUs, residual battery charge) per manufacturer guidance.
- Use ESD-safe handling for boards and modules, no carpet, no wool sleeves.
- Avoid moisture; never apply liquids near vents or connectors.
- If you smell smoke, see scorch marks, or feel uneven heat, stop and escalate.
Verification checklist
After applying the fix on your Fortinet device, confirm:
- The original symptom is no longer reproducible.
- Related features (status LEDs, app sync, paired accessories) still work.
- The device responds to a soft reboot without the fault returning.
- Any error codes that were on display have cleared.
- Documentation (your service log, the brand companion app) reflects the change.
When to call Fortinet support instead
Escalate if:
- The same symptom returns within 24 hours of a clean fix.
- You see physical damage (burn marks, swollen battery, cracked PCB).
- The device is in warranty and a hardware replacement is the cheaper outcome.
- Repair requires specialised tools you don't own (alignment jigs, calibration software).
- Following the official path keeps the warranty intact, which matters more than the time spent.
More frequently asked questions
How often should I run preventive checks?
Quarterly for most consumer devices; monthly for production / commercial devices. Set a calendar reminder so the device stays healthy between issues.
Will this void my warranty?
Applying official firmware updates and following the user manual will not affect warranty. Opening sealed components, jumping safety circuits, or using third-party parts can void warranty in most jurisdictions.
What if my model isn't exactly the same revision?
Cross-check the model code on the rating plate against the manufacturer support page. Major firmware generations sometimes shift the menu path; the option is usually under a similarly-named section.
Is it safe to apply during business hours?
If the device is in production use, apply during a scheduled maintenance window. Most procedures need 2-15 minutes of downtime. Capture pre-change state so you can roll back if needed.
How long does this fix usually take?
Most users complete the steps in 20-45 minutes the first time, and 5-10 minutes on subsequent runs once the menu paths are familiar.
Topology deep dive
The FortiGate 60F is a desktop-to-1U next-gen firewall built around Fortinet's SoC4 ASIC. In the BFSI perimeter designs I run, these almost always live as an HA active-passive pair, FGCP cluster, so a single chassis fault should never be a site outage. The interface layout is port1-port7 GE, wan1/wan2, dmz, ha/mgmt, fed by single external 12V DC adapter.
The ASIC offload is the part people forget when troubleshooting hardware. Traffic that is NP6-Lite or NP6XLite offloaded never touches the CPU, so a 'CPU looks fine but packets drop' symptom often points at the NPU, not the control plane. Keep that in your head before you chase ghosts in top.
The HA heartbeat runs over dedicated ha links. When a member goes missing, the first question is always: did the box die, or did the heartbeat link die? Those are two completely different repairs and the CLI tells them apart in seconds.
Configuration walkthrough
Start with state capture, not a reboot. The order matters: get system status tells you the build and uptime, execute sensor list exposes PSU voltages, fan RPM and board temperatures, and diagnose hardware deviceinfo nic dumps per-port PHY status. On the FortiGate 60F, a fan reading 0 RPM or a 12V rail sagging below 11.4V on execute sensor list is your smoking gun.
If the box is part of an HA pair, run diagnose sys ha status before you touch anything. If the surviving member already promoted itself to primary, your fault is contained and you can work the dead unit at leisure during a window rather than in a panic.
# Baseline the hardware state
get system status
diagnose hardware sysinfo
diagnose hardware deviceinfo nic
# Power, fan and sensor telemetry
execute sensor list
diagnose hardware deviceinfo
# HA / cluster member health
get system ha status
diagnose sys ha status
# Collect everything for FortiCare TAC
execute tac report
Troubleshooting commands by platform
| What you are checking | Command (FortiOS CLI) |
|---|---|
| Build, serial, uptime | get system status |
| PSU / fan / temp sensors | execute sensor list |
| Per-port PHY / link | diagnose hardware deviceinfo nic port1 |
| Interface counters | get hardware nic port1 |
| HA cluster state | get system ha status |
| Crash log | diagnose debug crashlog read |
| Memory / conserve mode | diagnose hardware sysinfo memory |
| TAC bundle | execute tac report |
Two FortiOS-specific gotchas catch people. First, conserve mode: if diagnose hardware sysinfo memory shows the box wedged at high memory, FortiOS drops into conserve mode and starts failing sessions, which reads like a hardware fault but is not. Second, the crashlog, diagnose debug crashlog read on the FortiGate 60F will name the failing subsystem (npu, kernel, wad) if there was a real panic. Read it before you RMA; a software panic is a firmware ticket, not an RMA.
India compliance and deployment notes
For a BFSI perimeter box, the RBI cyber-security framework and the MeitY DPDP Act both push you toward logging discipline and clean change control, so do not skip the execute tac report capture even when you are confident, it is your evidence trail. Procurement-wise, public-sector and bank tenders run the FortiGate 60F through GeM, and the FortiCare/FortiGuard bundle is usually quoted separately on the BoQ. A typical hardware swap lands at Rs 24,000 to Rs 72,000 INR ($290 to $865 USD) if the unit is out of FortiCare; inside FortiCare advance replacement, your cost is the logistics, not the box.
One India-specific habit: confirm the unit is a MeitY-cleared / TEC-approved SKU before you RMA into a bank DC. I have watched a replacement get stuck at the DC security desk because the serial did not match the approved asset register. Raise the FortiCare RMA early, the advance-replacement courier from the Mumbai logistics hub to a Tier-2 town branch can take two to four working days.
A real fault I worked
I got a 6am call from a broking firm's NSE colo rack at BKC: the perimeter FortiGate 60F had dropped, and the branch network behind it was dark. The HA partner had not promoted, which already told me the heartbeat link, not just the box, was involved. On console, execute sensor list showed one fan at 0 RPM and the board temp climbing past 78C, the unit was thermally throttling itself into a reboot loop.
The real fix was boring and fast: the dead fan had let dust-caked heat build, and the HA cable had been re-routed during a recent rack tidy so the heartbeat was flapping. I forced the surviving member to primary with diagnose sys ha reset-uptime on the good box, restored service, then RMA'd the faulty FortiGate 60F under FortiCare. The replacement reached the Gurugram site in two days. Moral: capture sensor and HA state first, because the obvious 'dead firewall' was really a fan plus a mis-cabled heartbeat.
More questions operators ask
Can I run this on a single (non-HA) FortiGate 60F?
Yes, but a standalone box means the repair is also the outage. For BFSI perimeter duty I never run these single; the marginal cost of a second unit is trivial next to one hour of a payments-switch being down.
How do I tell a firmware panic from a real hardware fault?
Run diagnose debug crashlog read. If it names kernel/wad/npu with a backtrace and the build is recent, it is a firmware ticket, open FortiCare and check the FortiGuard PSIRT before you RMA. Sensor faults (fan 0 RPM, sagging rails) are hardware.
Does opening the chassis void FortiCare?
For a PSU or fan that is field-replaceable on the FortiGate 60F, follow the FRU procedure. Cracking sealed boards yourself voids cover, raise an RMA and let advance replacement handle it.