n8n vs Inngest: what I would change about my production n8n workflow

If a node-based workflow has grown past a handful of steps because of waiting, reminders, and retries, move that specific logic into code before a second customer needs the same flow, not after. That's not a verdict against n8n. The workflow behind this piece has run in n8n production for a year, and nothing about n8n broke it. It's a threshold, drawn from the actual shape of one workflow, not a feature chart of two products.

We have not run Inngest in production. Say that upfront, because it decides how to read everything below. The n8n side of this piece is a year of measured production use. The Inngest side is a prototype that got built in a development environment and never shipped, because the project it was built for fell through before launch. Read the n8n half as evidence and the Inngest half as "here's what building it looked like," not as a finished comparison between two tools doing the same job.

What runs in n8n, and what it actually costs to keep running

The workflow is a customer follow-up automation: a lead signs up, gets a first message within a minute, answers three qualification questions one at a time, gets a scheduling link, receives reminders on working days, and gets escalated to a call list if nobody responds. Built in n8n, it grew to 91 nodes and 5 schedule triggers, with state in Google Sheets and a history log in Supabase. It has run in production since October 2025, a full year, and a container restart leaves workflows, credentials, and history intact. What that instance costs in server bills, from four real invoices rather than an estimate, is broken down in what it really costs to run n8n self-hosted.

None of that node count is a sign of n8n struggling. Waiting, reminders, and retries are genuinely hard to express visually, and 91 nodes is roughly what it takes to do that properly with schedulers and a spreadsheet standing in for memory. The cost shows up elsewhere. Serving a second customer with the same flow would mean copying the entire 91-node workflow and keeping separate copies of its state in sync across Sheets, Supabase, and Airtable, the exact part of the build that already cost the most effort the first time. Version control is its own problem: the workflow lives as JSON exports with a version number tracked in the filename, which is fine for one workflow owned by one person and gets harder to trust the moment two copies both need the same fix, since there's no diff between versions, only two files and a naming convention.

The one real incident on this workflow landed in October 2026: runs started failing intermittently with "DNS server returned an error" on calls to Google Sheets. It looked at first like an expired OAuth connection, since that's the usual cause for that kind of failure. The actual cause was the hosting provider's own DNS. The fix was pointing the container's DNS at 1.1.1.1 and 8.8.8.8 and restarting it, and the costly part came after: a retry that lands on top of the next scheduled run can process the same record twice, so recovering from an incident like this means checking for duplicate records, not just fixing DNS and moving on.

Why we looked at Inngest, and what actually got built

In September 2026, a different customer wanted a new, multi-tenant version of the same follow-up pattern. Instead of copying the n8n workflow again, we looked at building that version in Inngest. The reasoning: waiting, retries, and reminders are part of how an Inngest function is written, built into the step model itself rather than assembled from scheduler nodes and an external spreadsheet. State lives in one place, so a new customer becomes an added row instead of a copied workflow.

What got built was a prototype, in a development environment, nothing more: webhook intake, a lead lifecycle handler, one Inngest function. The pilot for that customer didn't go ahead at the end of September, so the Inngest version never went into production and never replaced anything. The n8n flow described above is still the one running today, DNS incident included.

The prototype wasn't wasted, though. Building even that much surfaced real friction in Inngest's current v4 API, the kind that doesn't show up until you're past the quickstart. EventSchemas, which older tutorials and some of the documentation still reference, is no longer part of the v4 API. createFunction now expects a triggers array rather than the single trigger field a lot of existing examples still show. And serve has no signingKey option at all in v4: that option lives on the Inngest client, and the docs recommend setting the INNGEST_SIGNING_KEY environment variable over passing a key in code, which is not where you look first if you learned the handler from an older example. None of that is a reason to avoid Inngest. It's the kind of thing that costs an hour or two the first time you hit it, and it's the one piece of this comparison that holds up regardless of whether the pilot had gone ahead.

Inngest's free tier covers 50,000 executions a month and 5 seats, according to its own pricing page, checked October 11, 2026. The next tier starts at $99/month for 1,000,000 executions. We have not run a workload on either tier ourselves, so treat these as the published numbers, not a bill.

The threshold, stated plainly

Stay in a visual workflow tool like n8n while a workflow serves one customer and nobody on the team writes code regularly. The visual builder stays the fastest path to something working, and it stays readable to people who aren't developers. A flow with an AI step can go from idea to working in about a day, and an assistant like Claude can generate importable n8n JSON directly, which keeps the barrier to a first version low.

Move the logic into code once two things show up together: waiting, retries, and reminders are eating more build time than the actual task the workflow performs, and a second customer, team, or tenant wants the same logic. Both of those showed up at the same time here, which is common. The kind of workflow that needs serious retry and wait logic in the first place tends to be exactly the kind that gets asked for a second time.

Who this applies to

If you're building a handful of automations that each serve one use case and nobody on the team writes code, n8n is still the faster path, including for the AI-step case above. Nothing about that changes once one specific workflow is the one being asked about; it changes once that workflow needs to repeat for someone else.

If you already write code, or you can see a workflow being requested by a second customer before you've even finished the first version, put the waiting, retry, and reminder logic in code from the start. Rebuilding it later, after the second case shows up, is exactly the work described above: a full copy of a 91-node workflow, two sets of state to keep in sync, and a filename convention standing in for version history.

What this doesn't tell you

This is one real production workflow and one real but unfinished prototype, not a controlled trial. There's no matched build-time comparison between n8n and Inngest for the same workflow built twice under the same conditions. We have not run Inngest in production, the prototype never left a development environment, and the pilot it was built for did not go ahead. The n8n side of this piece is measured: a real workflow, running for a year, with a specific node and scheduler count and one logged incident. The Inngest side is a partial build plus the API pitfalls it surfaced, not a finished system that's been carrying real traffic.

Inngest doesn't run a public affiliate or partner program. We checked its own site and found a generic referral clause in its Terms, not a sign-up-and-get-a-link program, and a separate technical Partner API aimed at integrations, not marketing affiliates. Any link to Inngest here carries no commission.

Sources

• n8n workflow structure, maintenance history, and the October 2026 DNS incident (91 nodes, 5 schedule triggers, live since October 2025, state in Google Sheets and Supabase): the author's own notes on running this instance, written down on October 11, 2026.
• Inngest prototype scope and outcome (development-environment build only, webhook intake, lead lifecycle handler, one function, pilot did not proceed, never went to production): the same notes.
• Inngest v4 API pitfalls hit while building the prototype (EventSchemas removed, createFunction expects a triggers array, no signingKey on serve): the same notes, checked against the Inngest serve() reference on inngest.com/docs/reference/serve, October 11, 2026, which lists client, functions, serveOrigin, servePath and streaming as the handler's options and states that signingKey is configured on the client, with the INNGEST_SIGNING_KEY environment variable recommended over the option.
• Inngest free tier and Pro tier pricing (50,000 executions/month, 5 seats on Free; $99/month for 1,000,000 executions on Pro): inngest.com/pricing, checked October 11, 2026.
• Inngest affiliate/partner program status (no public program found, only a generic referral clause in the Terms and a technical Partner API aimed at integrations): our own check of inngest.com, its Terms and its partner documentation, October 11, 2026.