FortiGate Reboots Every Two Hours: An Automation Stitch Case Study

QCS's public account describes a firewall that became unresponsive, restarted and returned to service around every two hours. Hardware checks passed. Investigators then connected warm-reboot information, interface-down records involving autod, and system events naming an Automation Stitch called IPS_AV_DB. The account says this stitch invoked a reboot after antivirus and IPS database updates. Removing or modifying the unintended action reportedly resolved the recurrence.

Fortinet publishes a closely matching troubleshooting case and documents this failure pattern. That vendor article is an explicit technical reference here, not a customer log captured by QCS. This expanded guide contains original operational checklists and teaching diagrams; it does not establish that the two public accounts represent separate incidents.

The public QCS post does not supply the customer's model, FortiOS build, complete configuration, HA layout, raw logs or observation duration. Do not infer any of those details from the illustration. The resolution is source-reported, not independently reproduced. The commands and correction workflow below were not executed on a FortiGate during preparation. [1][2]

A signature database contains detection information used by antivirus and intrusion prevention. A firmware image is the operating software of the firewall. These are different update processes. This case concerns a configured response to a signature-update event, not proof that updating signatures inherently requires a firewall restart.

An Automation Stitch is a rule connecting a trigger, meaning a condition or event, to an action, meaning the response to perform. Think of it as an if/then checklist; that is a memory aid, not a literal description of internal process scheduling. The useful question is not only 'What happened before the reboot?' but 'Which enabled rule was allowed to act on that event?'

Inspect both native system actions and CLI-script actions. Fortinet documents a system-action type capable of rebooting without an interactive confirmation prompt. Therefore an operator should not assume a command-confirmation dialog will protect the device.

A script may also invoke a disruptive command. Read the whole action and its permissions; do not execute it to see what it does. IPS_AV_DB is the reported object's name, not a mandatory default name on other firewalls. [5][6]

A warm reboot describes a software-initiated restart. Administrative operations, upgrades and other changes can produce that classification. It does not, on its own, prove automation or eliminate firmware defects. Likewise, interface-down messages during a restart do not by themselves prove faulty interfaces. Preserve the surrounding sequence instead of interpreting one line in isolation.

HQIP is Fortinet's hardware diagnostic tooling. A pass does not detect every hardware malfunction, configuration error or operating-system bug. Some diagnostic procedures are disruptive and require maintenance planning. This guide does not ask beginners to run HQIP, reset a device or reinstall firmware in production. Retain an existing authorized test report if one is available, and follow the appropriate support process for additional hardware testing.

Prepare a timeline with the event timestamp, timezone, device/member identity, evidence source and what the observation actually establishes. Align these clocks before comparing events from separate systems. A useful working hypothesis becomes stronger when an enabled configuration explains a repeated event sequence; an absent log is not proof that an action never ran. Log retention, collection gaps and an incomplete view of a cluster can all leave uncertainty. [3][4]

Step 1: Confirm the incident owner, authorization, exact model/build and the business services affected. Record whether the device is standalone, a member of an HA cluster, or managed in a Security Fabric. Do not change global or device context by guessing. Arrange the responsible administrator if your current access cannot see the relevant settings.

Step 2: Secure a supported configuration backup and a tested recovery path that will survive a management interruption. A show-command transcript is an inspection record, not automatically a restorable backup. Save the suspect stitch, trigger and action settings, their references, and the currently approved update settings in the private change record. Do not upload full configurations or logs to public tools.

Step 3: In the correct FortiGate console, gather the observational outputs below. In the GUI, inspect the System Events around the interruption and the installed release's Security Fabric > Automation view. Read the named stitch, its trigger, linked actions and target devices. If the UI labels differ, consult that build's administration guide rather than editing a similarly named object.

Step 4: Write down the sequence you can actually substantiate: update event, matching stitch execution, action target and reboot. Separate configuration showing capability from logs showing execution. If the chain is missing or contradictory, keep investigating other reboot causes; do not force this case onto a different incident. [7][8][3]

A console is the command window for the device. Open the authorized FortiGate CLI console or approved terminal session, confirm the device name and required administrative context, and type one command at a time. The cards below inspect existing status or configuration; they do not enable continuous debug or run an Automation Stitch. Never type them into a Windows command prompt expecting it to configure the firewall.

Inspect the default-inclusive update schedule where supported. Standard show output normally omits default values, so an absent line does not necessarily mean a feature is disabled. Record the version/build and check command help for that exact release. A permission error or unavailable command is a reason to stop that check and consult the administrator, not to grant yourself broader rights.

The important safety boundary is execution: do not click Test Automation Stitch or run a diagnose automation test command while a disruptive action remains attached. Reading a rule and testing it are different operations. Do not clear logs, reboot for convenience, or paste a downloaded diagnostic script into production. Keep sensitive serial numbers, addresses, administrator names, scripts and tokens out of screenshots that will be shared publicly. [10][8]

After the evidence identifies an unintended reboot path, obtain approval for the smallest effective correction. Inspect every stitch that references the same action and every configured destination before deciding whether to unlink, modify or retire an action. A shared action definition can serve more than one workflow; changing it globally may disrupt unrelated controls.

Record which target and reference you intend to change and compare that with the baseline before saving.

A temporary disable of the specific suspect stitch may be a containment option only after its other actions and operational consequences are assessed and the incident owner approves. It is not a recommendation to disable all automation. Do not turn off FortiGuard antivirus/IPS updates or weaken inspection to prevent recurrence. Reducing update frequency merely postpones the same incorrectly attached response.

The case does not provide enough configuration to justify a universal delete or set command. Apply the approved edit through the installed release's documented workflow, then read back the settings. If a useful notification is retained or substituted, verify its destination and data exposure separately; do not send configuration files to an unapproved mailbox or webhook. Changing a rule should improve safety without creating a new disclosure path. [7][6][5]

Agree an observation window with the service owner based on the device's actual update configuration and recent incident history. Two hours is the cadence in the public account, not a universal FortiOS default. Fortinet documents a change from automatic to daily defaults starting with FortiOS 7.4.10 and 7.6.5. An existing installation's settings and logs, rather than that release-note default alone, determine its behavior.

Observe a legitimate update check and, when new definitions are available, a successful installation. Record the attempt time, result and database versions. 'No Updates' is different from a failed check, and an attempt is different from a newly installed database.

Do not force a risky update or fabricate an update event merely to close the incident. If the relevant trigger has not naturally occurred, label that part of validation pending.

Correlate the later events with uptime and the absence of the unintended reboot action, then repeat the original business-service checks. Test approved browsing or application access, relevant VPN service and monitoring; inspect HA member health if applicable. One responsive management page is not a complete service check.

Record pass, fail or not tested with times and observers. The reported resolution remains a source claim; these steps are a proposed validation plan, not measurements performed for this article. [9][1]

Define rollback before editing: name the owner, recovery access, saved baseline and failure condition. Do not blindly restore an entire backup or re-enable a known disruptive reboot action. If the correction harms another required workflow, the incident owner must choose a narrowly scoped recovery that preserves service while keeping the demonstrated hazard contained. Document the remaining risk rather than treating the old configuration as automatically safe.

If interruptions continue after the suspected action is removed from the relevant execution path, reopen the diagnosis. Preserve new reboot reasons and timestamps. Power-related evidence, kernel failures, resource pressure, firmware changes or a different automated operation require their own investigation. Escalate with a sanitized timeline, exact build, configuration excerpts and the tests actually performed. Do not assert a vulnerability or hardware defect without supporting evidence.

The durable improvement is an automation register: an owner, purpose, trigger, action, targets, privileges, review date and validation method for each consequential rule. Review reboot, shutdown and configuration-changing actions before enabling them. For assistance, bring a sanitized evidence set to QCS network troubleshooting support.

No paid service is required to read this guide or use the browser-local Config Lens tool, and this article does not claim a guaranteed diagnosis from a single log line. [3][6]