Config drift and unauthorised changes are hard to catch after the fact. The nice thing about FortiOS is you don't need a SIEM to know the instant someone changes something — an automation stitch fires the moment the change is logged, and pushes an alert straight to wherever your team lives.

A stitch is two pieces: a trigger (something happened) and one or more actions (do this). That's the whole model.

Automation stitch flow TRIGGER config-change event STITCH match → act WEBHOOK → Slack / Teams EMAIL → NetOps event-based · fires the instant the change is logged
FIG.01 / Automation stitch — a config-change event fires a webhook and an email in one hop

The trigger: a config-change event

Every configuration change writes an event log. We hang the trigger off that event. Easiest in the GUI — Security Fabric → Automation → New Automation → Trigger: FortiOS Event Log, then pick the configuration-change event. In CLI:

config system automation-trigger
    edit "on-config-change"
        set trigger-type event-based
        set event-type event-log
        set logid 44547
    next
end
The event log ID for a config change varies by FortiOS version. Don't trust a number from a blog — make one change, run execute log display (or filter the event log for type=event subtype=system), and read the real logid off your own box before you wire the trigger.

The actions: webhook + email

Two actions, fired in parallel. A webhook to chat is the one people actually notice:

config system automation-action
    edit "notify-chat"
        set action-type webhook
        set protocol https
        set method post
        set uri "hooks.example.com/services/XXXX"
        set http-headers "Content-Type: application/json"
        set http-body "{\"text\":\"⚠ Config changed on %%log.devname%% by %%log.user%% from %%log.ui%%\"}"
    next
end
config system automation-action
    edit "email-netops"
        set action-type email
        set email-to "netops@example.com"
        set email-subject "FortiGate configuration changed"
    next
end

The %%log.field%% tokens pull straight from the triggering event — so the alert already tells you who changed what, from which interface, before you've even opened the GUI.

Wire them together

config system automation-stitch
    edit "alert-on-change"
        set status enable
        set trigger "on-config-change"
        config actions
            edit 1
                set action "notify-chat"
            next
            edit 2
                set action "email-netops"
            next
        end
    next
end

Test it

Change something harmless — a policy comment, an address object — and watch the channel:

Within a second of hitting end, the webhook lands: "Config changed on FGT-EDGE-01 by admin from GUI(10.0.0.20)." No polling, no external collector — the box told on itself.

Where this earns its keep

  • Change control — every change announces itself, so the record is live, not reconstructed later.
  • Catching the unexpected — a change you didn't schedule shows up immediately, which is exactly when you want to know.
  • Fabric-wide — the same pattern rides the Security Fabric, so downstream FortiGates can raise the alert centrally.
A stitch isn't monitoring — it's a reflex. The value isn't the alert, it's the latency: you find out while the change is still fresh in someone's terminal, not at the next audit.

Keep the trigger tight (one event type) so the channel stays signal, not noise. A stitch that cries wolf gets muted, and a muted alert is worse than none.