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.
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, runexecute log display(or filter the event log fortype=event subtype=system), and read the reallogidoff 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.