Get started
Reason
AgentsQuoxMindAgentic TeamsMirrorQuoxLensRemember
QuoxMemoryBrain2CompoundingQuoxPlanCodebase MirrorAct
QuoxFlowQuoxEngineQuoxAgentQuoxChatAutonomyRun
EnterpriseOrganisationsPowers & ToolsmithQlusterQuoxBastionInterfaces
QuoxMCPQuoxCLIQuoxTerminalQuox ConsoleQuoxBoxGovern
HITL ApprovalsQuox SecurityAgent HonestyQuoxVaultAI GovernanceProve
For AuditorsVerifiable AI OpsLoggingEU AI ActCompliance SuiteChannels
Matrix RoomsDiscord ProTelegram ProQuoxSignalCoreCommsAll products A-ZGet started
OverviewArchitectureProtocols
AEEAOCLVOLTWARDReference
GlossaryAPI ReferencePlugin SDKDockerAll products A-Zn8n is observable, and on the Enterprise tier reasonably well instrumented, but it is not auditable in the sense a compliance reviewer means, because nothing it records is tamper-evident.
Short answer: n8n is observable, and on the Enterprise tier it is reasonably well instrumented. It is not, out of the box, auditable in the sense a compliance reviewer means, because nothing it records is tamper-evident. That distinction is worth about twenty minutes of your time before your next control review. (If you are the reviewer rather than the operator, the auditor page is the shorter read.)
This piece is written for people who run n8n on real business processes. It is not an argument for ripping it out.
More than the sceptics assume.
Execution data. Every run can persist inputs, outputs and node-by-node progress. You control what is kept: on error, on success, on progress, and whether manual runs are saved. Pruning is on by default, with EXECUTIONS_DATA_MAX_AGE at 336 hours (14 days) and EXECUTIONS_DATA_PRUNE_MAX_COUNT at 10,000 executions. Annotated executions, for example those with tags or ratings, are never pruned (docs).
Workflow history. Previous versions can be viewed, restored, cloned or downloaded as JSON. Full history is an Enterprise feature; Cloud Pro gets the last five days, and everyone gets the last 24 hours (docs).
Log streaming with audit events. Enterprise only, on Cloud and self-hosted. n8n emits workflow lifecycle events, node execution events and a genuine audit event category covering user login success and failure, credential creation and sharing, workflow created, deleted, activated and deactivated, package installs, and 2FA enforcement changes. Destinations are syslog, a generic webhook, or Sentry, with per-destination event filtering and optional payload anonymisation (docs).
A security audit command. n8n audit produces a risk report covering unprotected webhooks, an outdated instance, unused credentials, expressions in SQL query fields and nodes touching the filesystem. It runs from the CLI, the public API or a node (docs).
Organisational controls. SSO, RBAC and projects, external secret stores and Git-backed source control sit in the Enterprise tier. n8n aligns its own programme to SOC 2, with annual independent audits, a SOC 2 report for enterprise customers and a publicly downloadable SOC 3 (n8n security page).
If your requirement is "we need to know what ran and see what broke", n8n covers it. That is a real capability and it is well built.
A record becomes evidence when three things hold.
Immutability. The record cannot be altered or removed after the fact without that alteration being detectable. Detectable is the operative word. Restricting who can delete is access control, not tamper evidence.
Identity binding. Each entry is cryptographically bound to the actor and to the specific version of the logic that ran, so that the record of an action and the thing that performed it cannot drift apart.
Independent verifiability. A third party can check the record without trusting the system that produced it, or the people who administer that system.
Execution history satisfies none of these. It is a mutable table in a database your team owns. n8n's public API exposes DELETE /executions/{id} (docs), pruning discards rows on a timer by default, and anyone with database access can rewrite a row directly with no trace. Logs an administrator can edit are records, not evidence.
That is not a criticism of n8n specifically; it describes almost every workflow tool in this category.
Here is where the difference bites. A compliance review will ask questions like these.
"Show me that this payment approval on 14 March was authorised by a person holding the approver role at that moment, and that the approval record has not been touched since." n8n can show an execution containing an approval step. It cannot prove the row was not edited afterwards, and the role assignment is a current-state lookup, not a fact captured at the time.
"The workflow logic changed between January and March. Show me which version processed this specific run." Workflow history holds versions and execution data holds runs. Binding a given execution to a given version, cryptographically rather than by timestamp inference, is not something the platform does for you.
"Reproduce this evidence for our external auditor without giving them access to your instance." You can export JSON. The auditor has no way to verify that the export matches what happened, because there is nothing to verify it against.
"This execution is from eleven months ago." Under default settings it was pruned after fourteen days.
None of this makes n8n unsafe. It means the artefacts it produces are operational telemetry, and a reviewer will treat them accordingly.
The pattern is consistent enough to be a genre. Search for n8n audit trails and you will find independent authors arriving at the same design: pipe every step into a Postgres table with correlation IDs, inputs, outputs, errors and timestamps, then call it an immutable run log. See Duckweave, Praxen and Vectorlane.
There is also a community template doing the same thing with n8n Data Tables, including secret redaction and a retention purge.
Build it. It is genuinely useful: correlation IDs make incidents tractable, and structured business events beat scrolling execution history.
But be clear about what you have. A Postgres table written by the same operator who runs the workflows, using credentials that workflow holds, on a database that operator can UPDATE, is not immutable. Calling it an immutable log in a control narrative is a claim you cannot support under questioning.
Append-only triggers and revoked delete grants raise the bar for a careless actor and do nothing against a determined one with database access. The bolt-on solves observability. It does not close the evidence gap, because the gap is structural.
Meanwhile the underlying request has been open in the community since June 2023: visibility on which user edited a workflow and when, and which user ran it manually (thread).
Reasonable hardening, in rough order of return:
EXECUTIONS_DATA_MAX_AGE deliberately to match your retention obligation rather than accepting the 14-day default, and watch the row-count cap, which will prune you regardless of age.n8n audit on a schedule and treat the report as a finding list.Briefly, and only because it is the reason we know this problem well.
First, the thing to be clear about: Quox does not depend on n8n in any way. QuoxFlow is an independent workflow engine with its own runtime, its own format and its own evidence chain; it is not an n8n add-on, layer or companion, and nothing in Quox runs on or through n8n. The importer exists purely as a convenience for teams arriving from n8n.
QuoxFlow is a TypeScript workflow engine built around auditability rather than retrofitting it. It has a one-way offline importer that converts an exported n8n workflow JSON into a QuoxFlow workflow, with no live n8n connection involved.
Every step emits AEE envelopes carrying causality links, and steps can emit hash-chained VOLT evidence with WARD witnessing, exported as bundles verifiable offline by someone who does not trust your instance. AEE, AOCL, VOLT and WARD are published as IETF Internet-Drafts. They are drafts, not standards, and we do not describe them otherwise.
The honest caveat on migration: QuoxFlow covers 18 node archetypes against n8n's several hundred node types, so the importer converts what maps and reports what does not rather than silently dropping it. Migration is a path rather than a rewrite, but it is a path with work on it. If your n8n estate is mostly HTTP calls, transforms, conditions and branching, that work is small.
If it leans on many vendor-specific nodes, it is not.
We found no n8n documentation describing signing, hash-chaining or any tamper-evidence mechanism on execution data, workflow history or audit events. Absence of documentation is not proof of absence, but if such a mechanism exists it is undocumented, which for audit purposes amounts to the same thing.
Several third-party blogs state specific audit-log retention tiers, for example 30 days on lower plans against unlimited on Enterprise. We could not confirm those figures in n8n's own documentation and would not rely on them. The 12-month audit history figure on n8n's security page refers to n8n's own infrastructure logging, not to your instance's execution data.
Sources: