n8n log streaming to a SIEM

Before any SIEM rule is written, the team needs a confirmed list of the events n8n sends, the fields in each event, and which destinations receive which events. This page describes the three event families only in general terms. Audit events record administrative actions in the instance, including changes to users and to stored credentials. Workflow execution events record runs of workflows, including the workflow each run belongs to and how it ended. AI node events record activity from nodes that call language models or agent tooling. Event names and structure can differ between versions, so use this list as a starting map and build parsers only from the schema documented for the version you have installed.

Security teams use credential-change records to see when a credential was created, edited or deleted, and who made the change. This matters because an edited credential can quietly point a workflow at a different account or system. Execution records answer a different question: whether a workflow ran at an unexpected time, from an unexpected trigger, or failed repeatedly after a change. The two are most useful together. A credential edit followed by a burst of failed executions is a pattern worth an alert. Write down which fields identify the actor, the object and the time in each event, and confirm that the actor is recorded for changes made through the API as well as through the editor. If the fields cannot support those questions, the volume of logs will not help detection.

Log streaming is a paid feature. The n8n pricing page supplied for this topic places log streaming in the Business and Enterprise plans, while the topic scope refers to the Enterprise plan, so confirm which tier includes the destinations you need before the budget or architecture is fixed. For each destination, whether syslog, a webhook or Sentry, confirm which event families it receives, whether the set can be filtered, how delivery is retried when the endpoint is unavailable, and what happens to events generated during an outage. Request these answers in writing from n8n or confirm them in the documentation for your version. An event that never reaches the SIEM cannot be investigated later.

In queue mode, the main instance handles triggers and webhooks, while workers and webhook processor nodes run the executions. Confirm whether events from workers and webhook processors reach the same destination as events from the main instance. If they do not, the SIEM will show an incomplete picture of executions, and a worker outage could hide failures. Plan one test for each process type: trigger an execution that a worker handles and confirm the event arrives. Separately, the main instance's encryption key must be shared with every worker and webhook processor so they can access credentials in the database. That requirement concerns credential access and is separate from log delivery, so a successful log test does not show that workers can run credentialed workflows.

Before go-live, record the answers in a short table with the event family, event name and version, fields, destination, filter, retry behavior and an owner for each row. Use the table to write detection rules and as evidence in your change-management file. Re-check it after every upgrade, because a renamed or restructured field can break a detection rule without any visible error on the n8n side. Assign one person to own the catalog and to review the release notes for each minor version you adopt. Upgrade planning is covered elsewhere on this page, but the event catalog should be one of the first items rechecked each time.

Prove the path from n8n to the receiver end to end before any alert rule depends on it. In a non-production n8n instance that forwards to the same receiver type as production, make one test credential change and run one test workflow execution, then search the SIEM for both events. Each should appear as its own record, and your team should be able to find it using only the fields your alert rules will use. Before you start, write down the test time, the credential name, the workflow name and the instance identifier, so you compare the receiver against known values. Confirm that the credential-change event names the actual change type and the user who made it, since those are the fields a monitoring rule will usually match.

Check the timestamp next. The receiver should show the time n8n recorded for each event, with any time zone or UTC offset carried through intact. Confirm which time zone n8n uses for event times, and which time zone the receiver assumes when a message arrives without one. Then confirm that the n8n host and the receiver both synchronize to a trusted time source through the NTP setup your platform team already runs. Even small clock offsets can split one incident across two correlation windows. Illustrative example: if n8n records a change at 09:14 local time and the receiver stores it as 07:14 because it assumed UTC, an alert that joins that change to a nearby login will never fire.

Confirm the source identifier on every test event. Each record should name the n8n instance that produced it, so a receiver fed by development, staging and production can be filtered correctly. Use the same hostname or instance field your alert rules will key on, and check the test event from each environment. Then search the receiver for the test secret value you placed in the credential. It should not appear anywhere in the stored event. Confirm with the n8n documentation for your version exactly what a credential-change event contains, and do not assume the content until you have seen it on your receiver.

When n8n's own record and the receiver disagree, the cause is usually in the pipeline between them, not in the event itself. Look for a syslog framing or transport setting that truncates or splits messages, a parser that expects different field names, or a filter or stream rule that drops events from one instance. If the receiver is Graylog, review the syslog input and any processing pipeline rules that touch these messages. Fix these issues before alert rules go live, then keep the passing test results, with dates, the test identifiers and the name of the reviewer, as acceptance evidence for your internal audit file.

Once the feed is live, the first ongoing task is confirming that events keep arriving at the receiver in the form your rules expect. Set a baseline for each event type your n8n instance sends, covering credential changes, workflow executions and AI node events, and alert when a type goes silent for longer than your team considers normal. Watch the receiving side as well as the sending side, because syslog listeners, webhook endpoints and Sentry projects can each drop events after a certificate change, a token rotation or a load spike. Test during staging how your n8n instance reports a failed delivery, and do not assume that a gap will show up in n8n's own logs. Assign a named owner for the feed and document the response when it stops.

n8n uses semantic versioning and ships minor releases roughly weekly, so the feed will face field changes more often than many platform teams expect. A new release can add, rename or restructure fields in the audit, workflow or AI node events, and a parser or alert rule that keyed on the old field name will then match nothing. Treat every n8n upgrade as a change to the feed. Before production, upgrade a staging instance that sends to a staging receiver, replay representative credential, execution and AI node events, and compare the parsed fields with the previous version. Receiver upgrades need the same test. A changed Graylog input, pipeline rule or Wazuh decoder can break working alerts from the other side, so run both upgrades against the same staging feed.

Alert rules need the same attention as the feed itself. Each new workflow, credential type or AI node that goes live can produce events that current rules either ignore or misclassify. Schedule a recurring review, and run one whenever your team adds a significant set of workflows or enables AI nodes. The review should ask whether each rule still matches a meaningful event, whether its thresholds reflect current execution volume and whether any new event type has an owner. In Graylog, this means reviewing event definitions and their notification targets. In Wazuh, it means reviewing custom rules and decoders together with the dashboard views that depend on them. Record each change with the n8n version and the date, so an incident responder can see which rules were in force when an event occurred.

Capacity planning on the receiver starts with measurement. Event volume grows with execution count, workflow count and the adoption of AI nodes, so ask the platform team to track daily event volume from the feed itself and review it each quarter. For Graylog, the system architecture guidance covers how to size log storage and the message journal, and Graylog recommends Data Node as the search backend. Confirm your storage design against that guidance before you set retention. For Wazuh, the indexer stores alerts and the Wazuh server can run as a cluster for horizontal scaling, so plan node count and disk around expected alert volume, not only the volume you see today. Set retention separately for each event type, since credential change records and execution records often have different retention needs.