What Is n8n? 3 Real Automations and Where It Breaks

By Lazar Milicevic · Published October 7, 2026 · 10 min read

If you run a business with 1-10 people, you're probably losing hours every day to the same three things: email, invoices, and lead follow-up. You can't afford a developer, and most n8n explainers are written by people who've never kept a flow alive for a real client. Here's what n8n actually is, three automations a small business can copy, and the exact point where I stop using it and write code.

What n8n is, in one paragraph

n8n is a visual workflow tool. You drag boxes onto a canvas, and each box is a step. The first box is a trigger (an email arrives, a form is submitted, a webhook fires). Every box after that is an action: summarize this, send it to Telegram, add a row to a sheet. Connect them with lines and the flow runs without you.

That's the whole mental model. For the basics, no code is required.

A few terms worth knowing before you build anything:

• Trigger node: starts the workflow. Polling triggers check an app on a schedule; webhook triggers wait for an app to call you.
• Action node: does one thing in one app (send a message, create a record).
• Execution: one run of a workflow, start to finish. You'll see this word in the logs and in hosted pricing.
• Credentials: stored logins for Gmail, Telegram, your CRM and so on, kept separate from the workflow itself.

One licensing note, because it trips people up. n8n isn't open source in the OSI sense. It uses a "fair-code" model with the Sustainable Use License, which limits use to internal business purposes. Running it for your own business is fine, and so is consulting, such as building workflows for clients. White-labeling it or hosting it and charging people for access is not. If you're a solopreneur automating your own operations, you're squarely in the allowed zone. If you're planning to resell n8n as a product, read the license first.

Automation 1: Email triage to Telegram

The flow: a client email lands in Gmail, an AI step writes a three-line summary with a priority tag, and the result is pushed to a Telegram chat on your phone.

What it replaces: opening the inbox every twenty minutes to find out whether anything is on fire. Instead you glance at Telegram, see what matters, and reply only to those messages.

The node chain is short:

Gmail Trigger (new email)
  → AI Agent / LLM node (summarize + classify)
  → IF node (priority = urgent?)
  → Telegram node (send message)

A prompt that works well for the AI step:

Read the email below. Return exactly:
1) A summary in max 3 short lines
2) Priority: URGENT / NORMAL / IGNORE
3) One suggested next action (max 10 words)

Rules: URGENT only if money, a deadline within 48h, or an angry client is involved.
Never invent details that aren't in the email.

The "rules" line matters more than people expect. Without a definition of urgent, a model will mark everything urgent, and you'll be back to checking the inbox anyway.

Two practical details I'd build in from day one:

• Keep a link back to the original. Include the Gmail message link in the Telegram message so one tap opens the full thread.
• Don't auto-reply yet. Triage first. Run it for a week, check where the priority tags were wrong, and tighten the prompt before you let anything send on your behalf.

On time saved: I haven't measured a clean hours-per-week number for this flow on my own inbox yet, so I'm not going to hand you one. Measure your own. Count how many times a day you open the inbox today, then count after a week with the flow. That's your real number.

Automation 2: Invoicing, and the first place it gets uncomfortable

The flow: a client confirms a job, and their name, amount and service flow into a template. An invoice is generated and sent.

Picture a business hand-typing something like two hundred invoices a week. That's an illustrative figure, not a client stat, but the point holds at any volume: every manual entry is a chance for a typo, and typos in billing mean awkward calls and late payments. Removing the typing removes that error class.

The basic version in n8n looks like this:

Webhook / Sheet Trigger (job confirmed)
  → Set node (map name, amount, service, date)
  → Document/PDF node (fill invoice template)
  → Gmail / Email node (send to client)
  → Sheets node (log invoice number + status)

For a simple case (one currency, one tax treatment, always-complete data) this works fine, and you should build it that way.

Here's the honest part: this is where the limit shows up. Invoicing logic gets branchy fast, especially once local format and compliance rules come into play:

• What if the amount field is empty?
• What if the client record is missing a tax ID?
• What if the invoice number sequence has to be gapless and a run fails halfway through?
• What if two confirmations arrive for the same job?

Every one of those is an IF node, then another IF node inside it, then a merge, then a fallback. In n8n that becomes a tangle of boxes that's painful to debug, because the logic is spread across a canvas instead of sitting in one readable function. For that job, custom code is the right call. Validation rules, sequence numbering and edge cases are exactly what code expresses cleanly and tests easily. If your invoices have to follow specific tax or formatting rules, confirm the requirements with your accountant or the relevant tax authority before you automate anything.

I haven't measured a confirmed before-and-after time per invoice that I'm willing to publish, so I'll skip that number rather than guess.

Automation 3: Lead follow-up in under a minute

The flow: a new lead fills out a form, the flow sends a first-touch message within a minute, logs the lead in your sheet or CRM, and pings you if they reply.

Speed is the whole point here. A lead contacted in the first few minutes is far more likely to answer than one contacted tomorrow. A human can't reliably hit that window at 9 p.m. on a Saturday; a flow can.

Form Trigger / Webhook (new lead)
  → Sheets / CRM node (create lead row)
  → Wait node (30-60 seconds, so it doesn't look robotic)
  → Email or SMS node (first-touch message)
  → Telegram node (notify you: "New lead: {{name}}")

This is n8n at its best, because it's pure glue between apps that already exist. No custom business logic, no compliance, no money moving. If a step fails, the worst outcome is a late follow-up, not a wrong invoice.

Two things that keep it from feeling spammy:

• Personalize with what the form gave you. Name and the service they asked about is enough.
• Stop the sequence on reply. If you add follow-up #2 and #3 later, check for a reply before each one sends.

Where n8n wins and where it loses

n8n wins on app-to-app glue: Gmail to CRM to Slack to Sheets, with simple branching, where the logic fits in a handful of boxes.

It loses on three things:

1. Custom business logic. Pricing rules, multi-step validation, anything with a lot of "if this, unless that."
2. Local compliance rules. Formats and requirements that change by jurisdiction and have to be exactly right.
3. Heavy error handling. Surviving failure when nobody is watching.

That third one deserves a closer look, because it's where most small-business automations quietly die.

What n8n gives you for failures

n8n does have error handling, and you should use it. You can assign an error workflow to each workflow in Workflow Settings. It runs when an execution fails (for example, to send you an email or Slack alert) and it must start with the Error Trigger node.

A minimal error workflow:

Error Trigger
  → Set node (build message: workflow name, error text, execution URL)
  → Telegram node (alert to your phone)

There's one catch the docs call out. If the failure happens in the main workflow's trigger node, the workflow never executes, and the error data has no execution ID or URL. Your alert arrives without a direct link to the failed run. So a broken Gmail credential at 3 a.m. gives you a vague alert and a hunt through the logs.

For AI steps, the AI Agent Tool node has an Enable Fallback Model option. When on, you connect a backup chat model for when the primary one fails or isn't available. That's a real reliability win for triage flows, and I'd turn it on.

Why it still gets fragile

Alerts tell you something broke. They don't fix it. When a flow fails at 3 a.m. and touches money, you need retries with sensible limits, idempotency (so a retry doesn't send the invoice twice), a safe fallback state, and a way to resume. You can build pieces of that on the canvas, but each piece is more boxes, and each box is more surface to debug. In code, the same behavior is a few functions with tests. That's the gap.

My decision rule, and the cost side

Here's the rule I use:

Many real systems end up as a mix. n8n handles the connections (triggers, notifications, passing data between apps) and code handles the hard decisions. That's the split I'd recommend: n8n-style glue on the outside, purpose-built code for anything with real consequences.

Self-hosted vs. hosted: do the math on your volume

Self-hosting n8n on a small home server costs close to nothing beyond hardware and electricity you'd run anyway. I haven't pinned down a confirmed monthly figure I'd publish, so measure your own. Hosted automation platforms usually charge per task or per execution, and that bill grows with your volume.

I can't give you n8n Cloud's current plan prices or execution limits here, since I couldn't confirm them against official pricing, so check the pricing page directly. What I can give you is the method:

1. Count your workflows.
2. For polling triggers, work out how often each one checks. A frequent schedule means many checks per day against the app it watches, whether or not anything new arrived. Whether an empty check also counts against your plan's execution limit depends on the trigger and the plan, so confirm that in the n8n docs or pricing page.
3. Add event-driven runs (form submissions, webhooks).
4. Compare the monthly total against each plan's limit.

Polling frequency is the sneaky one. A flow that checks Gmail very often multiplies the number of API calls to Gmail and, depending on your plan and setup, can push up your usage. Webhook triggers avoid that, so use them wherever the source app supports them.

If you outgrow a single self-hosted instance, the official docs describe queue mode as the best-scaling option for larger self-hosted volumes: one main instance receives triggers and webhooks, separate workers run the executions, and Redis acts as the message broker between them. Most solopreneurs will never need it, but it's good to know the ceiling isn't a single box.

A note on AI nodes

If you build the email-triage flow, you'll use n8n's AI nodes, which implement LangChain's JavaScript framework. You pick the agent, LLM and memory per node. Two version warnings from the docs are worth acting on now rather than later:

• The Conversational Agent has been deprecated since n8n 1.82.0. New or updated AI Agent nodes use the Tools Agent, and node version 1 of the AI Agent node is removed in n8n 3.0. If you copy an old tutorial, check which agent type it uses.
• The LangChain Code node is marked deprecated, hidden from the nodes panel and self-hosted only, and the docs say to avoid it. If a template depends on it, rebuild that step.

This is the kind of thing that breaks a flow six months after you built it, which is one more reason to put a failure alert on everything.

Where bizflowai.io fits in

bizflowai.io is about practical AI automation for solopreneurs and small teams. The goal is to take repetitive work off a small team's plate without handing them a tangle of nodes they can't debug.

Want more like this?

I publish practical AI automation and GenAI engineering content under the BizFlowAI name.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, practical AI automation for solopreneurs and small teams.

Visit bizflowai.io for more.