The Complete FortiGate execute Command Reference

Every FortiGate admin knows execute ping. Most know execute backup config. Almost nobody knows what else is sitting in that branch, which is a shame, because execute is where the FortiGate stops being a config file and starts being a device you can actually operate.

This is the full tour: what execute is, how it differs from config and diagnose, and a category-by-category walk through the commands and their options. Target is FortiOS 7.4 and 7.6 on a hardware FortiGate. Where a command is model-gated or VDOM-scoped, it says so.

What execute Actually Is

FortiOS splits its CLI into four verbs, and the split is not cosmetic.

Verb	What it does	Persists?
config	Changes the running configuration	Yes, written to flash
get	Reads configuration and operational state	No
diagnose	Reads and manipulates internal daemon state	No
execute	Runs an action against the device, right now	Depends on the action

config is declarative. You describe the state you want, and FortiOS reconciles it. execute is imperative. It performs a verb and returns. Rebooting, backing up, generating a certificate, bringing a tunnel up, formatting a log disk: none of those are states you can declare, so they live under execute.

The important consequence: most execute commands take effect the instant you press Enter. There is no candidate config, no end, no commit. execute factoryreset does not ask twice on every model. Treat the execute branch with the same respect you would give rm -rf on a production box.

The Three Rules Worth Internalizing

Rule 1: execute is not backed up. Backing up the config captures config state. It does not capture the fact that you ran execute update-now or that your ping options are still set to a 1400 byte payload from last Tuesday. That state is ephemeral and per-session or per-boot depending on the command.

Rule 2: The tree is model-specific and VDOM-specific. A FortiGate 40F has no execute disk branch because it has no disk. A FortiGate-VM has no execute modem. Inside a VDOM, execute reboot is gone because rebooting is a global action.

Rule 3: Your admin profile gates the branch. An admin with a read-only access profile will not see most of the branch. If a command you expect is missing, check config system accprofile before you check the release notes.

Finding the Real List on Your Box

Do not trust any reference, including this one, over the device in front of you. FortiOS ships a command tree dumper:

FGT # tree execute

That prints the entire execute subtree for the model, firmware, VDOM scope, and admin profile you are currently in. Pipe it to a capture log and diff it against another box. It is the single most useful undocumented trick in the CLI.

Narrower forms:

FGT # execute ?
FGT # execute vpn ?
FGT # execute vpn certificate local ?
FGT # execute ping-options <tab>

The ? gives you the branch with descriptions. Tab completion gives you the tokens. And exec is a valid abbreviation everywhere execute is, as is any unambiguous prefix, so exec ping works and so does exe ping.

Field note: tree execute output on a FortiGate 600F running 7.6 runs to several hundred lines. On a 40F it is a fraction of that. If you write runbooks that span models, generate them per platform or you will hand a tech a command their box does not have.

System Control and Power

The commands most likely to get you a phone call.

execute reboot [<comment>]
execute shutdown [<comment>]
execute factoryreset
execute factoryreset2
execute set-next-reboot {primary | secondary}
execute date [<yyyy-mm-dd>]
execute time [<hh:mm:ss>]

execute reboot takes an optional comment string that is written to the event log. Use it. A reboot with execute reboot "planned maintenance CHG0044821" in the log is the difference between an audit finding and a closed ticket.

execute shutdown halts the OS and powers down where the platform supports it. On most FortiGate hardware you still need to pull power or hit the switch afterward. On a VM it stops the guest.

execute factoryreset wipes everything, including interface addressing, and returns the unit to defaults. execute factoryreset2 does the same but preserves the management interface configuration and static route, so a remote box comes back reachable instead of coming back on 192.168.1.99 in a rack you cannot get to. If you are resetting anything you cannot physically touch, factoryreset2 is the command you want.

execute set-next-reboot selects which firmware partition boots next on models with dual boot partitions. This is the safe-upgrade primitive: load new firmware into the secondary partition with execute restore secondary-image, set the next boot to secondary, reboot, and if it goes badly you set it back and reboot again.

execute date and execute time set the clock manually. They are only relevant when NTP is unavailable or you are deliberately testing certificate expiry behavior. Run them with no argument to read the current value.

Command	Blast radius	Confirmation prompt
execute reboot	Traffic outage for the boot duration	Yes
execute shutdown	Device down until physically restarted	Yes
execute factoryreset	Total config loss, unit unreachable	Yes
execute factoryreset2	Total config loss, mgmt reachable	Yes
execute set-next-reboot	None until next reboot	No

Configuration Backup and Restore

This is the branch you should be scripting.

execute backup config flash <comment>
execute backup config ftp <filename> <server>[:<port>] [<user>] [<password>] \
     [<backup-password>]
execute backup config sftp <filename> <server>[:<port>] <user> <password> \
     [<backup-password>]
execute backup config tftp <filename> <server> [<backup-password>]
execute backup config usb <filename> [<backup-password>]
execute backup config usb-mode <backup-password>
execute backup full-config {flash | ftp | sftp | tftp | usb} ...

The distinction people miss: config gives you the delta from defaults, full-config gives you every setting including the defaults. The short one is what you want for change review and version control, because a diff between two config backups is readable. The full one is what you want when you are chasing a behavior difference between two units and need to see what a default actually resolved to on each.

The optional trailing <backup-password> encrypts the file. If you set it, the restore will demand it, and there is no recovery path if it is lost. This is not the same as config system global set private-data-encryption, which is a different mechanism entirely.

execute backup config flash <comment> writes a revision into the local revision store rather than shipping it off box. Pair it with config system global set revision-backup-on-logout enable and you get automatic snapshots.

Restore mirrors it:

execute restore config flash <revision-id>
execute restore config ftp <filename> <server>[:<port>] [<user>] [<password>] \
     [<backup-password>]
execute restore config sftp <filename> <server>[:<port>] <user> <password> \
     [<backup-password>]
execute restore config tftp <filename> <server> [<backup-password>]
execute restore config usb <filename> [<backup-password>]

A config restore reboots the unit. Not “may reboot.” It reboots. Schedule accordingly.

Log and object backups live in the same branch:

execute backup disk {alllogs | <log-type>} {ftp | tftp | usb} ...
execute backup memory {alllogs | <log-type>} {ftp | tftp | usb} ...
execute backup ipsuserdefsig {ftp | tftp | usb} ...
execute backup vmlicense {ftp | tftp | usb} ...

execute backup disk only exists on models with local storage. execute backup memory is the equivalent for models logging to RAM, which on a small box is the only local logging you have and is gone on reboot.

Field note: the source interface for FTP, SFTP, and TFTP transfers is chosen by the routing table, not by the command. If the backup server sits behind a policy that expects a specific source, set config system global set source-ip or you will spend an hour debugging a firewall policy that is working exactly as configured.

Firmware Management

execute restore image ftp <filename> <server>[:<port>] [<user>] [<password>]
execute restore image tftp <filename> <server>
execute restore image usb <filename>
execute restore secondary-image {ftp | tftp | usb} ...
execute restore av-sig {ftp | tftp | usb} ...
execute restore ipsuserdefsig {ftp | tftp | usb} ...
execute restore vmlicense {ftp | tftp | usb} ...
execute restore src-vis {ftp | tftp} ...

execute restore image upgrades and reboots immediately. There is no staging, no confirmation beyond the initial prompt, and no going back. The unit validates the image signature, writes it to the active partition, and boots into it. If the image is wrong for the model, the check fails and nothing happens, which is the one piece of protection you get.

execute restore secondary-image is the same operation against the inactive partition on dual-partition models. It does not reboot. This is the command that makes a maintenance window survivable, because the pattern becomes: stage to secondary, verify with diagnose sys flash list, execute set-next-reboot secondary, execute reboot, validate, and roll back by flipping the pointer if the new build misbehaves.

execute restore av-sig and execute restore ipsuserdefsig push signature packages manually. You need these on air-gapped units and on OT deployments where FortiGuard is unreachable by design.

execute restore vmlicense applies a .lic file to a FortiGate-VM. On FortiFlex deployments the token-based flow is execute vm-license <token> instead.

Reachability and Path Testing

The branch everyone thinks they already know.

execute ping <host>
execute ping6 <host>
execute traceroute <host>
execute traceroute6 <host>
execute telnet <host>
execute ssh <user>@<host>

execute ping resolves names using the DNS configured in config system dns, so a ping failure to an FQDN might be a DNS failure, not a reachability failure. Ping the IP to split those apart.

ping-options: the part that matters

execute ping has no inline flags. All the tuning lives in a separate stateful command that sets options for subsequent pings in your session:

execute ping-options adaptive-ping {yes | no}
execute ping-options data-size <bytes>
execute ping-options df-bit {yes | no}
execute ping-options interface <interface | auto>
execute ping-options interval <seconds>
execute ping-options pattern <2-byte-hex>
execute ping-options repeat-count <count>
execute ping-options reset
execute ping-options source {auto | <source-ip>}
execute ping-options timeout <seconds>
execute ping-options tos <8-bit-hex>
execute ping-options ttl <hops>
execute ping-options use-sdwan {yes | no}
execute ping-options validate-reply {yes | no}
execute ping-options view-settings

Read that list again, because it is doing more work than it looks like.

source is the one that solves most tickets. By default the FortiGate sources ICMP from the egress interface chosen by the routing table. If you need to prove that a remote site can reach your internal server subnet across a tunnel, you have to source from an address inside that subnet:

FGT # execute ping-options source 10.10.10.1
FGT # execute ping 192.168.50.10

Without that, you are testing the tunnel from the FortiGate’s WAN IP, which is not in any phase 2 selector, and you get a silent failure that looks like a broken VPN.

df-bit plus data-size is the MTU discovery pair. Set df-bit yes, then walk data-size until the pings stop:

FGT # execute ping-options df-bit yes
FGT # execute ping-options data-size 1472
FGT # execute ping 8.8.8.8

1472 bytes of payload plus 8 bytes of ICMP header plus 20 bytes of IP header equals 1500. If that succeeds and 1473 fails, your path MTU is 1500. This is how you catch the PPPoE and IPsec overhead problems that present as “the VPN is up but large files hang.”

use-sdwan yes forces the ping through SD-WAN rule evaluation instead of the plain routing table. Without it, you are testing a path that production traffic may never take.

validate-reply yes checks that the returned payload matches what was sent, which catches the rare but real case of a middlebox mangling packets.

interface pins the egress interface, which is different from pinning the source IP. Use source when you care about what the far end sees. Use interface when you care about which link it leaves on.

reset puts everything back to defaults, and you should run it at the end of every troubleshooting session. Ping options persist for the life of your CLI session and will happily confuse the next engineer, or you, twenty minutes later.

view-settings dumps the current values. Run it first if a ping is behaving oddly.

traceroute-options

execute traceroute-options device {auto | <interface>}
execute traceroute-options queries <count>
execute traceroute-options reset
execute traceroute-options source {auto | <source-ip>}
execute traceroute-options use-sdwan {yes | no}
execute traceroute-options view-settings

Same stateful model, same reset discipline. source matters for exactly the same reason it does with ping.

telnet and ssh

execute telnet <host> and execute ssh <user>@<host> originate a client session from the FortiGate itself. These are genuinely useful for proving Layer 4 reachability to a port when you have no other jump host, and execute telnet <host> <port> will tell you whether a TCP handshake completes. They are also, from a hardening perspective, exactly the pivot capability an attacker with admin access wants. If your access profile does not need them, do not grant them.

Layer 2, Layer 3, and Routing Operations

execute clear system arp table
execute dhcp lease-list [<interface>]
execute dhcp lease-clear {<ip> | all}
execute interface dhcpclient-renew <interface>
execute interface pppoe-reconnect <interface>
execute router clear bgp {all | as <as-number> | ip <neighbor-ip> | external |
     dampening | flap-statistics} [soft {in | out}]
execute router clear ospf process
execute router restart

execute clear system arp table flushes the entire ARP cache. On a busy box this is a brief, self-inflicted forwarding hiccup while entries repopulate. It is the right tool when you have moved an IP between devices and the FortiGate is holding a stale MAC, and the wrong tool when you are just poking at things.

execute dhcp lease-list is your fastest answer to “what is on this VLAN.” It shows IP, MAC, hostname, and expiry for every lease the FortiGate’s own DHCP server has handed out. execute dhcp lease-clear <ip> releases one, all releases the lot.

execute router clear bgp is the one that deserves care. The bare all form does a hard clear: every session drops and rebuilds, and on a box with a full table that is a real outage. The soft variants are what you almost always want:

FGT # execute router clear bgp ip 10.255.0.1 soft in
FGT # execute router clear bgp ip 10.255.0.1 soft out

soft in re-evaluates received routes against your inbound policy without bouncing the session. soft out re-advertises. soft in requires set soft-reconfiguration enable on the neighbor beforehand, because otherwise the FortiGate never stored the pre-policy routes and has nothing to re-evaluate. Set it before you need it, not during the incident.

execute router restart restarts the entire routing daemon. Every protocol adjacency drops. This is a last resort, not a troubleshooting step.

FortiGuard, Licensing, and Central Management

execute update-now
execute update-av
execute update-ips
execute update-geo-ip
execute update-src-vis
execute send-fds-statistics
execute upd-vd-license <license-key>
execute vm-license <token>
execute forticarrier-license <license-key>
execute central-mgmt {register-device | set-mgmt-id | update | unregister-device}

execute update-now triggers an immediate FortiGuard check across all subscribed services. It is the first thing to run when a UTM feature is behaving as though its database is stale, and it is the fastest way to prove whether the box can reach FortiGuard at all. Follow it with diagnose debug application update -1 if it fails and you want to know why.

The targeted forms (update-av, update-ips, update-geo-ip, update-src-vis) pull individual packages. update-geo-ip is the one people forget, and stale geo-IP is a common cause of “my geography-based policy stopped matching.”

execute upd-vd-license <key> raises the VDOM count on hardware models. execute vm-license <token> is the FortiFlex entitlement flow on VMs. execute forticarrier-license converts a FortiGate to FortiOS Carrier, which is a one-way trip.

execute central-mgmt handles the FortiManager relationship: register, unregister, force a config update pull.

Certificates and PKI

execute vpn certificate local generate {rsa | ec | dsa} ...
execute vpn certificate local export {tftp | usb} <cert-name> <filename> [<server-ip>]
execute vpn certificate local import {tftp | usb} <filename> [<server-ip>]
execute vpn certificate ca import {tftp | scep | auto | usb | est} ...
execute vpn certificate crl import {tftp | scep | usb | online} ...
execute vpn certificate remote import {tftp | usb} <filename> [<server-ip>]

This branch is where the CLI’s positional-argument style hurts most. execute vpn certificate local generate takes a long, order-sensitive list: certificate name, key size or curve, subject, then optional country, state, organization, unit, email, SAN, and CA server. Getting position seven wrong produces a certificate that generates cleanly and fails validation later.

Do not type it from memory. Walk it:

FGT # execute vpn certificate local generate rsa ?

The ? at each position tells you what the next token is. It is slower and it is correct.

Two practical notes. First, generating a local certificate creates a CSR, not a usable certificate, until you export it, get it signed, and import the result. The GUI hides this; the CLI does not. Second, if you are signing on a FortiAuthenticator for RADSEC or any mutual-TLS use, the certificate must carry the right Extended Key Usage. A cert with serverAuth where the peer wants clientAuth will fail the handshake with an error that points nowhere useful.

VPN Operations

execute vpn ipsec tunnel up <phase2-name> [<phase1-name>] [<local-gateway>]
execute vpn ipsec tunnel down <phase2-name> [<phase1-name>] [<local-gateway>]
execute vpn ike gateway clear [name <phase1-name>]
execute vpn ike gateway flush [name <phase1-name>]
execute vpn ike gateway list [name <phase1-name>]
execute vpn sslvpn del-tunnel <index>
execute vpn sslvpn del-web <index>
execute vpn sslvpn del-all
execute vpn sslvpn list

execute vpn ipsec tunnel up takes the phase 2 name first. This trips up everyone coming from another vendor, because the mental model is “bring up the tunnel,” and the tunnel feels like a phase 1 concept. In FortiOS the SA you are establishing is the phase 2 SA, so that is the first argument. If your phase 2 name is not unique across phase 1s, supply the phase 1 name as the second argument.

execute vpn ike gateway clear versus flush is worth knowing. clear tears down the IKE SA and lets it renegotiate. flush removes the gateway state entirely. When a tunnel is stuck in a half-established state where one side thinks it is up and the other does not, flush on the confused side is usually the fix, and it is far less disruptive than bouncing the interface.

For SSL VPN, execute vpn sslvpn list shows connected sessions with an index, and del-tunnel and del-web kick a single session by that index. del-all kicks everyone, which is the correct response to a compromised credential and the incorrect response to “one user is having trouble.”

High Availability

execute ha manage <cluster-index> <admin-name>
execute ha synchronize {start | stop | status}
execute ha disconnect <serial-number> <interface> <ip> <netmask>
execute ha failover {set | unset | status} <group-id>
execute ha ignore-hardware-revision {status | enable | disable}

execute ha manage <index> <admin> drops you into the CLI of another cluster member. Get the index from get system ha status. You come back with exit. This is how you read the secondary’s logs and interface counters without physically consoling into it.

execute ha failover set <group-id> forces the primary to give up its role. This is the command for testing failover during a window, and the pairing matters: set puts the unit into a permanent failover state where it will not take the primary role back. You must run execute ha failover unset <group-id> to release it. People forget the unset, then wonder six weeks later why their preferred primary never came back.

execute ha disconnect <serial> <interface> <ip> <netmask> removes a unit from the cluster and simultaneously configures it with a management address on the interface you name, so it comes out of the cluster reachable rather than stranded. It is a well-designed command that almost nobody uses because they do not know it exists.

execute ha synchronize controls config sync. status is diagnostic. start and stop are for the specific case where sync is failing and you need to control the retry, and they are not something to run casually.

execute ha ignore-hardware-revision enable lets units with different hardware revisions form a cluster. Fortinet does not love this and neither should you, but when a warranty replacement comes back on a newer revision at 2 AM, it is the command that gets you back to a cluster.

Command	Reversible	Use during a window
execute ha manage	Yes, exit	Anytime
execute ha synchronize status	Read-only	Anytime
execute ha failover set	Yes, requires unset	Yes
execute ha disconnect	Rejoin manually	Yes
execute ha ignore-hardware-revision	Yes	Yes

Logging and Disk

execute log filter category <category>
execute log filter device {disk | memory | faz | fds}
execute log filter field <field> <value>
execute log filter start-line <n>
execute log filter view-lines <n>
execute log filter dump
execute log filter reset
execute log display
execute log delete
execute log delete-all
execute log delete-filters
execute log delete-rolled <log-type> <index>
execute log list
execute log fortianalyzer test-connectivity
execute log-report reset
execute formatlogdisk
execute disk list
execute disk format <ref-id>
execute disk scan <ref-id>
execute erase-disk <ref-id>

The log filter model is the same stateful pattern as ping-options: you build a filter across several commands, then act on it. Build, dump to verify, display or delete, reset.

FGT # execute log filter device disk
FGT # execute log filter category traffic
FGT # execute log filter field srcip 10.10.10.50
FGT # execute log filter view-lines 40
FGT # execute log filter dump
FGT # execute log display

execute log filter dump before you act is not optional discipline. A stale filter from earlier in your session will silently scope execute log delete to something other than what you think, and execute log delete deletes exactly what the filter matches.

execute log delete-all ignores the filter and removes everything. execute log delete-filters clears the filter set, which is easy to confuse with delete-all at 3 AM and is exactly the kind of naming that earns a post-incident review.

execute log fortianalyzer test-connectivity is the fastest FortiAnalyzer triage there is. It reports registration status, connection state, and how many logs are queued. Run it before you touch anything else.

execute formatlogdisk wipes and reinitializes the log partition. It reboots the unit. It also reclaims a disk that has been carved up for WAN optimization, which is the usual reason you would run it.

execute disk list enumerates storage with reference IDs that the other disk commands consume. execute erase-disk is a multi-pass secure wipe and is how you meet a decommissioning requirement, not a maintenance step.

Users, Authentication, and Tokens

execute fsso refresh
execute fortitoken activate <serial-number>
execute fortitoken sync <serial-number> <token-code>

execute fsso refresh forces the FortiGate to re-pull group and user information from the FSSO collector agent. When a user was added to a group in AD ten minutes ago and their policy still is not matching, this is the command before you start blaming the collector.

execute fortitoken activate activates a hard token that shipped in a deactivated state. execute fortitoken sync resynchronizes a hard token whose internal clock has drifted, which happens with older FortiToken 200 units and presents as “my code is always rejected.”

Switch and AP Controller

execute switch-controller get-conn-status [<switch-id>]
execute switch-controller get-sysinfo [<switch-id>]
execute switch-controller diagnose-connection <switch-id>
execute switch-controller restart-switch <switch-id>
execute switch-controller factory-reset <switch-id>
execute switch-controller set-standalone <switch-id>
execute switch-controller custom-command <command-name> <switch-id>

execute wireless-controller reset-wtp <wtp-id>
execute wireless-controller restart-acd
execute wireless-controller restart-wtpd
execute wireless-controller upload-wtp-image {ftp | tftp | usb} <filename> \
     [<server-ip>]
execute wireless-controller list-wtp-image
execute wireless-controller delete-wtp-image

execute switch-controller get-conn-status with no argument lists every managed FortiSwitch with its state, serial, and firmware. It is the first command in any FortiLink triage.

execute switch-controller set-standalone cuts a switch loose from FortiLink management. It is how you retire a switch from the fabric or hand it to another team, and it is not reversible from the FortiGate side once the switch is standalone.

execute switch-controller custom-command runs a command you have predefined under config switch-controller custom-command against a managed switch. This is the escape hatch for FortiSwitch settings the FortiGate does not expose.

execute wireless-controller restart-acd restarts the AP control daemon. Every AP re-registers, which means a brief client outage across the whole site. execute wireless-controller reset-wtp <wtp-id> reboots one AP, which is what you actually wanted.

execute wireless-controller upload-wtp-image stages AP firmware onto the FortiGate so it can push it to APs. list-wtp-image shows what is staged. delete-wtp-image clears it, which matters on small units where the images eat flash.

USB, Batch, and Support

execute usb-disk list
execute usb-disk format
execute usb-disk rename <old-name> <new-name>
execute usb-disk delete <filename>
execute batch start
execute batch end
execute batch status
execute batch lastlog
execute tac report
execute sensor list
execute sensor detail
execute cli check-template-status
execute cli status-msg-only

execute batch is the most underused command in FortiOS. execute batch start puts the CLI into a mode where commands are queued rather than executed, execute batch end runs the whole set, and execute batch lastlog shows what happened.

Why it matters: it makes remote config changes atomic-ish. If you are changing the address on the interface you are connected through, a normal CLI session cuts you off halfway through and leaves the box in a broken state. In batch mode the queue runs after you have finished typing, so both the interface change and the route change land together.

execute tac report generates the diagnostic bundle Fortinet TAC asks for. Run it before you open the ticket, not after they ask.

execute sensor list and execute sensor detail read hardware sensors: temperatures, fan speeds, voltages, PSU state. On a box that is behaving strangely under load, this is a thirty-second check that occasionally ends the investigation immediately.

Commands That Are Not There

Half of knowing a CLI is knowing what it does not have. These are the ones people reach for and do not find on a FortiGate:

What you type	What is wrong	What to use
execute nslookup	Exists on FortiMail, FortiADC, and FortiVoice, not FortiGate	execute ping <fqdn>, diagnose test application dnsproxy 6
execute traceroute -n	execute commands take no dash flags	execute traceroute-options
execute ping -c 5 <host>	Same, no inline flags	execute ping-options repeat-count 5
execute write memory	FortiOS saves on end, there is no save verb	Nothing, it is already saved
execute copy running-config	Not a Cisco box	execute backup config <target>
execute show tech	Wrong vendor’s name	execute tac report

The ping -c one is worth dwelling on. The absence of inline flags is not an oversight, it is the design: options are session state, set separately, persisting until reset. Once that clicks, the whole -options pattern stops being annoying and starts being predictable.

Quick-Reference Matrix

Command	Category	Reboots?	VDOM or Global
execute reboot	System	Yes	Global
execute shutdown	System	Halts	Global
execute factoryreset2	System	Yes	Global
execute set-next-reboot	System	No	Global
execute backup config	Config	No	Both
execute restore config	Config	Yes	Both
execute restore image	Firmware	Yes	Global
execute restore secondary-image	Firmware	No	Global
execute ping	Network	No	Both
execute ping-options	Network	No	Both
execute traceroute	Network	No	Both
execute clear system arp table	Network	No	Global
execute dhcp lease-list	Network	No	VDOM
execute router clear bgp	Routing	No	VDOM
execute update-now	FortiGuard	No	Global
execute vpn certificate local generate	PKI	No	Both
execute vpn ipsec tunnel up	VPN	No	VDOM
execute vpn sslvpn del-all	VPN	No	VDOM
execute ha manage	HA	No	Global
execute ha failover set	HA	No	Global
execute log filter	Logging	No	Both
execute log delete-all	Logging	No	Both
execute formatlogdisk	Logging	Yes	Global
execute fsso refresh	Auth	No	VDOM
execute switch-controller get-conn-status	Switch	No	VDOM
execute wireless-controller reset-wtp	Wireless	No	VDOM
execute batch start	Ops	No	Both
execute tac report	Support	No	Global

Field Notes

Wrap the destructive ones in automation stitches. config system automation-action can fire a CLI script. If you find yourself running execute backup config ftp by hand on a schedule, you have already built the worst version of a job that FortiOS will run for you.

execute bypasses the config-change audit trail you think you have. A config backup diff will show you what changed. It will not show you that someone ran execute vpn sslvpn del-all at 4 PM on a Friday. Event logging catches it, so make sure config log setting has event logging on and that the events are actually leaving the box.

Read-only admins should not have this branch. The default super_admin profile has everything. A monitoring account that only needs get and diagnose should not be able to execute reboot. Check config system accprofile and set the relevant permission groups to read-only.

Session state is per-session, not per-user. Two admins in two SSH sessions have independent ping-options. This is good, and it also means that when you and a colleague are both troubleshooting, their view-settings output does not describe your session.

Abbreviate, but not in runbooks. exec ping-opt source 10.1.1.1 works. It also becomes unreadable in a document that someone follows at 3 AM under pressure. Type it long in writing and short at the keyboard.

Closing

execute is the operational surface of the FortiGate. It is the branch that reboots the box, wipes the disk, drops every VPN session, and forces a firmware roll, and it is also the branch that holds ping-options source, execute batch, execute ha disconnect, and execute log fortianalyzer test-connectivity, which between them will resolve more tickets than any other four commands in FortiOS.

Run tree execute on the box in front of you. Compare it to this list. Whatever is different is what your model, your firmware, and your admin profile are telling you about themselves.

---