n8n Automation: 12 Workflow Examples Worth Copying

A workflow that runs green in the editor and dies quietly at 3am on a Tuesday is the normal outcome, not the exception. The node graph was never the hard part. The hard part is what happens on the fourteenth run, when the upstream API returns a 429, the webhook fires twice because the sender retried, the schedule trigger overlaps with the previous execution that has not finished, or the Postgres table holding execution data has grown to forty gigabytes and the editor takes ninety seconds to load. Good n8n automation is mostly a set of defensive habits applied to a handful of recurring patterns.

What follows is twelve n8n workflows worth copying, each given three ways: the node sequence, the specific failure mode it hits once real traffic arrives, and the fix. They assume you already run n8n, self hosted or cloud, and know what an IF node does. Nothing here is a pitch. The last two sections are honest about where a node based engine is the right answer and where it is more machinery than the job needs.

What separates a demo n8n automation from one that survives production

The editor lies to you in three reliable ways, and every failure mode below traces back to at least one of them.

Pinned data. Pinned output makes iteration fast and makes your branches untested. The IF node you wrote against three pinned items has never seen an empty array, a null field, or a string where you expected a number.

The test webhook URL. It only listens while you have the canvas open. Half the "it worked yesterday" reports are a workflow that was never activated, or a sender still pointed at the /webhook-test/ path.

Manual executions. They do not behave like production runs. Workflow static data written with $getWorkflowStaticData is not persisted from a manual run, so every cursor, dedupe cache and last-seen timestamp you tested by hand behaves differently once the schedule takes over.

Assume all three. Then build.

Revenue and billing workflows

1. Inbound lead router. Webhook trigger, Set to normalise the payload, HTTP Request to an enrichment API, Remove Duplicates, HubSpot or Pipedrive upsert, Slack notification to the owning rep. Failure mode: duplicate contacts. Form tools and ad platforms retry webhooks when they do not receive a fast 200, and n8n has already accepted the first one. Fix: respond immediately with a Respond to Webhook node placed before the slow work, and dedupe on a real key, the submission id or a hash of email plus form id, stored in a database table rather than workflow static data. Static data survives restarts poorly and does not scale past one instance in queue mode.

2. Failed payment recovery. Stripe Trigger on invoice.payment_failed, IF on livemode, Switch on invoice amount, Gmail node for the customer, Slack for finance on high value accounts, append a row to a tracking table. Failure mode: customers get emailed four times because Stripe fires the event on every retry in the dunning schedule, and your test-mode events hit the same production workflow. Fix: gate on livemode first, dedupe on the event id, and branch on attempt_count so the message escalates rather than repeats.

Failed payment recovery with a retry guard

Stripe event

invoice.payment_failed arrives on the webhook

Guard

Drop test mode events and any event id already seen

Branch on attempt

First failure, second failure, or final notice

Email the customer

Message text changes with the attempt number

Alert finance

Only above the value threshold

Log the outcome

One row per invoice so the next run can read state

3. Quote to invoice handoff. CRM trigger on deal stage change, HTTP Request to fetch line items, Code node to compute totals and tax, accounting API to create a draft invoice, Slack confirmation. Failure mode: a rounding difference between the CRM total and the invoice total, discovered at month end by a bookkeeper. Fix: compute once, in one place, and add a check node that compares your computed total against the CRM total and routes any mismatch to a human queue instead of posting. The broader sequencing question, which finance processes to automate before others, is worked through in Accounting Automation Software: What to Automate First.

Reporting and data movement workflows

4. Nightly warehouse extract to a sheet. Schedule Trigger, Postgres query, Aggregate, Google Sheets append. Failure mode: the query returns 400,000 rows, n8n holds every item in memory, and the container is OOM killed. Fix: paginate with LIMIT and OFFSET inside a Loop Over Items node, or push the aggregation into SQL so n8n moves hundreds of rows rather than hundreds of thousands. n8n is an orchestrator, not a query engine. If the extract is genuinely large, the right shape is a warehouse job that n8n triggers and monitors, a pattern that makes more sense once you understand the cost model described in Amazon Redshift Data Warehouse: Architecture and Costs.

5. Cross tool morning digest. Schedule Trigger, parallel HTTP Request branches to your tracker, support desk and analytics, Merge, Code node to build the message, Slack. Failure mode: one branch 401s after a credential rotation and the digest posts anyway, minus a third of its content, and nobody notices for two weeks. Fix: set each HTTP node to continue using its error output, then have the Code node explicitly name any source that failed inside the message. A digest that says "support data unavailable" is honest. A digest that silently omits it teaches people to trust a number that is wrong.

6. Competitor and release monitoring. RSS Feed Read or HTTP Request on a changelog, Remove Duplicates, an LLM node to summarise, Slack or Notion. Failure mode: after a restart or a workflow rename, everything reprocesses and the channel gets ninety messages. Fix: key deduplication on the item GUID and persist it outside the workflow. Also cap the batch: if more than ten new items appear in one run, that is a signal your state was lost, not that ten things happened, so route the overflow to a review branch rather than the channel.

AI workflows that need a validation gate

7. Support ticket triage. Webhook or Zendesk trigger, LLM classification with a structured output parser, Switch on the returned category, tag and assign, escalate anything above a confidence threshold. Failure mode: the model returns prose, a code fence, or a category you never defined, and the Switch drops the item into a fallback branch that does nothing. Fix: validate the parsed output against an explicit enum in a Code node, and make the fallback branch a real destination, a human queue, not a NoOp. Every AI node needs an answer to "what happens when the output is malformed", and the answer is never "it will not be".

8. Invoice and receipt extraction. Gmail trigger with attachments, Extract from File, LLM extraction to structured JSON, arithmetic validation, create a draft in the accounting system. Failure mode: a hallucinated total, or line items that do not sum to the invoice total, posted straight into the ledger. Fix: never auto post. Create drafts. Add a node that sums the extracted line items and compares to the extracted total, and fail the item on any mismatch beyond a cent. Extraction is a first pass, not an approval.

9. Document ingestion into a vector store. Drive or S3 trigger, Extract from File, Text Splitter, Embeddings, vector store upsert. Failure mode: every edit to a document re-embeds the whole file and leaves the old chunks in place, so retrieval returns two versions of the same paragraph and the newer one loses. Fix: store a content hash per document, skip unchanged files, and delete existing chunks by document id metadata before upserting. Retrieval quality degrades from stale duplicates faster than from missing content. If the goal is explanation rather than retrieval, the distinction is worth reading in Automated Data Interpretation Tools That Explain the Why.

Operational workflows that keep the instance healthy

10. Paginated API sync with backoff. Schedule Trigger, HTTP Request with pagination, Loop Over Items, Wait between batches, upsert, cursor written to a table. Failure mode: the provider rate limits at page nine, the run fails, and the next run starts from page one and re-imports everything. Fix: write the cursor after each successful page, enable Retry On Fail with a wait between tries, and make the upsert idempotent on the provider's record id.

11. Approval with a Wait node. Form or webhook trigger, Slack message with approve and reject buttons, Wait node resuming on webhook, branch on the decision. Failure mode: approvals that never resume. The approver ignores it, the execution sits forever, and nobody knows the request is stuck. Fix: always set a resume timeout, and route the timeout path to an escalation, not to failure. Also confirm your reverse proxy does not strip the resume URL path, which is the most common cause of a button that appears to do nothing.

12. Workflow backup and version control. Schedule Trigger, n8n public API to list and export workflows, Code node to normalise JSON, GitHub node to commit. Failure mode: the backup restores as a graph full of broken credentials, because credentials are encrypted with N8N_ENCRYPTION_KEY and that key was never backed up anywhere. Fix: back the key up separately and treat it with the seriousness of a database password. Commit workflow JSON only, never credential exports, into a private repository. Engineering teams that already run review discipline on code can extend the same review to workflow diffs, using the triage patterns in Automate Code Review Triage Across Engineering Teams.

The five failure modes behind almost every broken workflow

Sort your own self hosted automation examples into this table before you debug them individually. Most incidents are one of five patterns wearing different node names.

How to test an n8n automation before you trust it

Four checks catch most of what the canvas hides.

Run it with an empty input. Every branch should still terminate somewhere sensible. Empty arrays are the single most common cause of a workflow that reports success and does nothing.

Break a credential on purpose. Rotate or revoke one token in a staging copy and watch what the workflow does. If it posts a cheerful summary anyway, fix that before you fix anything else.

Fire the trigger twice within a second. This simulates a retry and tells you whether your idempotency is real.

Let it run against a week of production volume before you rely on the output. Set a per-workflow error workflow so failures reach a channel rather than only the executions list, and set execution data pruning so the database does not become the bottleneck.

Teams choosing between n8n and other engines should apply the same tests to every candidate. The selection criteria are laid out in How to Choose a Workflow Automation Platform in 2026, and the tradeoff between visual builders and code-first tools is unpacked in No-Code vs Low-Code Automation Platforms: How to Pick.

When self hosted n8n automation is the right answer

n8n earns its keep in four situations, and they are worth stating plainly because the alternative is not always simpler.

The data cannot leave your network. Self hosting on your own infrastructure, with your own encryption key, is a hard requirement in plenty of regulated and air gapped environments. No hosted product solves that.

The logic is genuinely branching. Loops, retries with backoff, conditional fan out, sub-workflows called with different parameters. A node graph is the right representation for that, and describing it in prose would be worse.

You need a custom node or arbitrary code. The Code node, community nodes and raw HTTP Request mean you are never blocked by a missing integration. You can call anything with an endpoint.

Volume is high and predictable. Queue mode with Redis and multiple workers handles serious throughput at infrastructure cost rather than per-task pricing.

The honest cost is maintenance. Someone owns upgrades, the database, the encryption key, the credential rotations, and the twelve failure modes above. That is a real job, not a side task.

Where a chat built automation is less to maintain

There is a large category of work that people build in n8n because they have n8n, not because it needs a node graph. It looks like this: read a few connected tools on a schedule, notice something, tell a person. The daily digest. The stalled deal alert. The invoice that has been unpaid for thirty days. The support queue summary. These are mostly queries with a delivery step attached, and the graph is a straight line.

Skopx is built for that category. It connects to nearly 1,000 tools a company already uses, Gmail, Slack, Stripe, HubSpot, QuickBooks, Google Analytics and the rest, and you build workflows by describing them in chat rather than wiring nodes. The same connections back a chat that answers with cited data from your tools, a morning brief, and an insights engine that surfaces risks and anomalies you did not ask about. It runs on your own AI key with zero markup on any major model, and pricing is Solo at $5 per month and Team at $16 per seat per month, listed on pricing.

Where it does not fit, stated clearly: Skopx does not replace a node based engine. There is no canvas, no custom code node, no community node ecosystem, no self hosted deployment inside your VPC, and no sub-workflow composition. It is not a dashboard builder, not a data warehouse, not an ETL tool and not a CRM. If your workflow needs a loop with backoff over a paginated third party API, build it in n8n. If your workflow is "every Monday, check these four tools and tell me what changed", the chat-built version is a fraction of the surface area to maintain, and plenty of teams end up running both: n8n for the machinery, a conversational layer for the questions and the routine alerts.

The useful test is whether a person reads the output. Machine to machine plumbing belongs in a workflow engine. Human facing summaries, which is most of what people actually build, do not need one. If you are designing the reporting side of this, Executive Dashboard Examples Leaders Actually Read covers what survives contact with an executive audience.

Frequently asked questions

What are the most common n8n use cases in real companies?

Lead routing, billing and dunning alerts, cross tool digests, support ticket triage, document ingestion for retrieval, and API syncs between systems that have no native integration. The pattern underneath most of them is the same: a trigger, a lookup or two, a decision, and a delivery step. The complexity almost always lives in error handling rather than in the happy path.

Is self hosted n8n cheaper than a hosted automation tool?

At high volume, usually yes, because you pay for infrastructure rather than per execution. At low volume, usually no, once you count the engineer hours spent on upgrades, database maintenance, credential rotation and incident response. Estimate honestly by pricing the maintenance time, not just the server.

How do I stop an n8n workflow running twice on the same event?

Three layers. Respond to webhooks quickly so senders do not retry. Dedupe on a stable external key, an event id or a record id, stored in a database table rather than workflow static data. And guard scheduled workflows against overlap by checking whether a previous run is still in flight before doing work.

Why does my workflow behave differently when I activate it?

Manual executions do not persist workflow static data, pinned data replaces live input, and the test webhook path is different from the production one. Any logic that depends on remembered state between runs will behave differently the moment the schedule or the production webhook takes over. Test with the workflow active before you trust it.

Can these workflow examples be rebuilt without a node editor?

The straight-line ones, yes. Anything that reads a few connected tools on a schedule, applies a rule and delivers a message can be described in a sentence on a platform that already holds the connections. Anything with loops, retries over paginated APIs, custom code or sub-workflows needs the node editor. Choose by shape, not by preference.