Make.com and n8n audit: what we check before retrofitting

A Dutch e-commerce SME called us last March about a workflow-agent retrofit. Their operations lead, one person also handling supplier ops and CS escalations, had a Make.com account with 67 active scenarios and a self-hosted n8n on a Hetzner box with another 23 workflows. Some scenarios talked to n8n via webhook. Some n8n workflows wrote back to Make. Nobody on the team could draw the graph.

Before we quote any of this work, we run an audit. It's not a sales tactic; we've walked away from three of them. The audit takes one engineer about two days and reads like a checklist because that's what it is. It scores three things specifically, in this order: scenario-version drift across the top 40 scenarios, webhook-secret rotation coverage on the top 25 endpoints, and which workflows would survive a self-hosted n8n cutover without losing the AVG-required execution log at three in the morning.

Here's what each one actually means.

Why the hybrid even exists

Make.com is what a non-engineer picks first. The UI is good, the templates work, and you can hand it to someone in marketing without a Slack channel for tickets. n8n shows up later, usually when the company hits an integration Make can't handle, or when a finance director asks why a SaaS bill is €890 a month for what is effectively Zapier with a different logo. So they install n8n on a single VPS, build the new workflow there, and now there are two automation platforms talking to each other over HTTP and assumption.

This is fine. We build new hybrids on purpose. The problem isn't the hybrid; it's that it grows for two years without anyone tracking what's coupled to what. By the time someone is ready for an AI-agent layer on top, email triage, order-routing logic, supplier comms, the substrate has eight unlabelled scenarios that nobody dares delete because "I think the warehouse needs it".

The maturity arc is depressingly consistent. Year one, marketing picks Make for a single use-case, lead capture, usually. Year two, operations inherits it and bolts on five more scenarios for order routing and CS triage. Year three, an engineer installs n8n on a spare VPS to dodge the Make pricing tier above 10,000 operations. By year four, the founder reads about AI agents and asks for one on top of the inbox. By that point the substrate has 90 unlabelled flows, four authors who left the company, and at least one webhook still pointing at a former contractor's ngrok tunnel. The ngrok part isn't a joke; we've seen it twice.

The audit exists to give a number to that fear.

Scenario-version drift, top 40

Make.com keeps a version on every scenario. Every time you edit, save, or roll back, the version number moves. What the dashboard doesn't show you is which scenarios have drifted from the version a colleague last reviewed. Over two years, in a 67-scenario account, you'll see a handful of scenarios on version 312 and others stuck on 4.

We pull the scenario list via the Make API and sort by run-count over the last 90 days. The top 40 by run-count covers, in our experience, somewhere between 92% and 97% of total executions. That's the slice that matters.

For each of those 40, we score:

• Drift severity — difference between current versionId and the version present in any export the client has on disk (Git, Drive, anywhere). No baseline export means automatic max drift score.
• Author concentration — how many distinct users edited the scenario in the last 12 months. One author with 80 edits is healthier than four authors with 20 each.
• Module-mix volatility — new module types added without a corresponding note in the scenario's "Notes" field.

A scenario that scores red on all three is what we call a fossil-in-motion: it runs every day, drifts every week, and nobody on the team can explain it. You don't retrofit an AI agent on top of a fossil-in-motion. You rebuild the underlying workflow first, or you exclude it from the agent's scope.

The Make API endpoint we hit, for anyone curious:

GET https://eu2.make.com/api/v2/scenarios?teamId=...&pg[limit]=100
Authorization: Token <mk_api_token>

The response gives you lastEdit, scheduling, and a usedPackages array. The drift calculation isn't in the API; it's a git diff between the exported blueprint JSON and whatever the client had archived. If the client has nothing archived, the audit becomes a baseline-creation exercise before anything else.

Webhook-secret rotation, top 25 endpoints

This is the section that fails the most audits. By a margin.

Every Make custom webhook and every n8n webhook node has a URL. Most clients secure them with one of three things: an HMAC signature on the body, a shared bearer token in a header, or, we wish this were rarer, nothing. Just an obscure URL and the prayer that nobody runs a subdomain scan.

We pull the top 25 webhook endpoints by inbound volume over 90 days. For each, we score:

• Secret presence — does the endpoint validate at all? HMAC, bearer, mTLS, or none.
• Rotation cadence — when was the secret last changed? Over 18 months is red.
• Storage hygiene — is the secret pasted into a scenario module as plaintext, or referenced from a connection or credential store?
• Blast radius — if this single secret leaked, how many other endpoints share it?

In about two-thirds of audits, the top 25 contains at least one webhook with no validation at all. In one in three, there's a webhook secret older than the company's youngest employee. Once, we found a webhook secret hardcoded into a Make scenario that had been forked, exported, re-imported, and shared in a Slack DM in 2022. That secret was still live.

The fix isn't romantic. You rotate, you wire HMAC verification on both ends, and you store secrets in Make connections or n8n credentials rather than module fields. n8n's documentation on webhook authentication covers the validation patterns end-to-end.

If the client wants an AI agent in front of any of these webhooks, and they almost always do, since agents love consuming events, this section has to be green before we sign.

AVG execution-log survivability at 03:00

This is the section that gets us walked out of a sales meeting twice a year, and it's the one we never skip.

Dutch SMEs processing personal data fall under AVG, the Dutch implementation of the GDPR. Article 30 of the GDPR requires a record of processing activities, and Article 5(2) requires that you can demonstrate compliance. In practice, when the Autoriteit Persoonsgegevens asks "show me the execution log for this automated decision on 14 March at 03:00", you need to produce it. Not approximate it. Produce it.

Make.com cloud retains execution logs based on your plan. n8n self-hosted retains whatever your database keeps and your prune settings allow. n8n's logging documentation spells out the retention controls; the defaults are not AVG-compatible for any workflow handling personal data.

For the audit's third score, we pick the top 10 workflows that touch personal data (customer email, name, order address, anything pseudonymisable back to a person) and ask one question per workflow: if we cut Make over to self-hosted n8n tomorrow, and the Autoriteit Persoonsgegevens asks for the 03:00 execution of this workflow six months from now, can we produce it?

The answer hinges on five things:

• Is EXECUTIONS_DATA_SAVE_ON_SUCCESS set to all (not none)?
• Is EXECUTIONS_DATA_PRUNE disabled, or is the prune window longer than your AVG retention obligation?
• Is the Postgres or MySQL behind n8n itself backed up nightly, with restore tested?
• Are the workflow's secrets and credentials versioned alongside the execution metadata?
• Does the workflow log enough to reconstruct the decision, the inputs, the branch taken, the output, rather than just "ran OK"?

Three of those are configuration. Two are architecture. The architecture ones are why some workflows survive the cutover and most don't.

In the e-commerce SME audit from March, of 23 self-hosted n8n workflows, exactly three were AVG-survivable at 03:00:

1. The Mollie payment-confirmation handler, because the developer who built it had been a CTO at a fintech and over-logged out of habit.
2. The supplier-PO generator, because it wrote its own audit trail to a dedicated Postgres table the rest of n8n didn't manage.
3. The customer-refund router, because it was the only workflow with saveExecutionProgress: true in its settings, set by accident during a debugging session.

That was the entire survivable surface. The other 20 workflows would have failed an AP inquiry. We wrote that into the report in plain Dutch.

What we do with the score

Every audit ends in a single page with three numbers and a recommendation. The numbers are out of 100, weighted: drift is 25, webhooks are 35, AVG survivability is 40. We weight AVG highest because it has a €20.000.000 ceiling on the fine, and because it's the gate that decides whether you can even safely run an agent on top of the workflow.

Above 70: we quote the agent retrofit, scope it to the green workflows, and write the rebuilds for the red ones into a phase-two SOW.

Between 40 and 70: we quote two weeks of remediation first. The retrofit comes after. We've never had a client argue this.

Below 40: we recommend a stack consolidation before any AI work. Usually this means moving the Make scenarios that matter into n8n, killing the ones that don't, and rebuilding the execution-log layer before anything else. About a third of the time, the client thanks us and goes elsewhere. That's fine.

The remediation work itself is unglamorous. Exporting blueprints into Git, rotating webhook secrets, writing the missing log statements, deduplicating overlapping scenarios, configuring n8n's prune window against a written retention policy. We scope it by workflow rather than by the hour, because hourly bills on this kind of cleanup always overrun and the client deserves a number they can plan against. A typical remediation phase for a stack scoring around 50 runs about two weeks of one engineer, sometimes three if the database layer needs a separate audit trail.

The smallest thing you can do today

Open your Make dashboard. Sort scenarios by execution count over the last 90 days. Look at the top five. For each one, ask: do I have the blueprint JSON exported anywhere? If the answer is no for even one of them, your drift score isn't a number yet, it's a question mark. Export the blueprints today and commit them to a private Git repo. Tomorrow you have a baseline.

When we built the workflow-agent layer for a Dutch wholesaler last winter, the thing we ran into was exactly this: their top scenario had been edited 84 times in 18 months with no exported baseline, and the agent we layered on top kept inheriting the drift. We ended up solving it by versioning every scenario blueprint into Git as part of our process automation retainer, with a nightly diff alert when anything moved. Three months later, the score moved from 41 to 88.