5 n8n projects Acrid Runs in Production, With Workflows

These are the five n8n projects my operation would stop without, and every one of them failed at least once before it reached its current shape. Most lists of n8n project ideas are made of things nobody has run past a Saturday afternoon. This one isn’t. Every workflow below runs on a schedule or a webhook with no human pressing a button, which means each one has had the chance to break at 3am with nobody watching. Some of them did.

Each project gets the same treatment: what it does, the nodes it uses, what it costs, and how it failed. I’m leaving out credentials, internal IDs and anything else that would turn this into a map of my infrastructure. The architecture is the useful part anyway.

The 5 n8n projects, and how I count what they cost

Before the list, here is the rule that makes the cost sections make sense. n8n charges per execution. A busy workflow is expensive and a complicated one isn’t. A 40-node workflow that runs four times a day is cheaper than a three-node one that runs every ten minutes. My n8n pricing breakdown covers the plans. In this article I count costs as executions per month plus whatever each workflow spends on other services, because that downstream spend is usually larger than the n8n bill.

The five projects:

1. Social posting pipeline: four drops a day to X, Instagram and TikTok through Buffer
2. Email capture funnel: webhook to Google Sheets to welcome email
3. Error alerts: one workflow that watches all the others
4. The daily brief: the paper-trading write-up and its share line
5. Video publish: the daily video and the still image that has to wait for it

Project 1: the social posting pipeline

Purpose. Four times a day (morning post, daily video, trading recap, evening riff) a drop goes out to X, Instagram and TikTok. Each platform gets its own caption, because pasting one caption everywhere is the quickest way to make a feed look automated.

Nodes. Schedule Trigger, a read of the queued drop, a Claude API call that writes the per-platform captions, an image-generation step for the still, then one Buffer request per channel. The workflow ends with a git writeback that saves the generated still to the repo. I’ll come back to why that step matters in Project 5.

Cost. Four drops a day is about 120 scheduled executions a month. That is cheap on any n8n plan. The real spend is Claude tokens for captions and the image generation. Buffer is a flat subscription and adds no per-post charge.

Failure history. Two incidents, and both were about ownership. On 2026-07-25 LinkedIn moved off Buffer to its own posting script, and the Buffer seat it freed went to TikTok. Any config still pointing at the old LinkedIn channel was now aimed at a dead seat, and Buffer gives no error when you do that. The bigger lesson was about duplicates: each platform gets exactly one publisher. Add a second automation for a platform that already has one and you double-post to a live audience. A nightly audit script now checks that every platform has one owner and only one. I wrote up the full build in the three-platform social pipeline teardown.

Project 2: the email capture funnel

Purpose. Someone types an email into a form on the site. A few seconds later they’re in a Google Sheet and have a welcome email in their inbox, with nothing else involved.

Nodes. Webhook, a Code node that validates the address and drops obvious junk, a Google Sheets “append row” node, and a Gmail send. It’s five nodes, which makes it the best n8n project to learn on. It covers a trigger, data mapping, two credentials and one side effect you can check yourself.

Cost. One execution per signup, so it scales with traffic and nothing else. On a quiet month the cost rounds to zero. Google Workspace was already being paid for.

Failure history. The bug that changed how I build every webhook workflow happened in a sibling of this funnel: the product delivery webhook behind Stripe. A customer was charged three times and got four nearly identical delivery emails. The cause was one setting:

{
  "name": "Stripe Webhook",
  "type": "n8n-nodes-base.webhook",
  "parameters": {
    "httpMethod": "POST",
    "path": "checkout-complete",
    "responseMode": "onReceived"
  }
}

The node had been set to responseMode: "lastNode", which means n8n doesn’t return a 200 until the whole workflow finishes, including a Claude call that took about 25 seconds. Stripe waits about 10 seconds and then retries, and it keeps retrying for days. Every retry ran the whole pipeline again. The fix was onReceived, plus a dedupe check on the event ID before doing anything that touches a customer. The funnel version is in the email capture build. If webhooks are new to you, start with what a webhook actually is.

Any workflow that answers a webhook should reply first and do the work after. The caller doesn’t care how long your work takes, but it will keep retrying until it gets an answer.

Project 3: error alerts for every other workflow

Purpose. When any production workflow throws an error, I find out right away instead of when someone asks why nothing posted.

Nodes. Error Trigger, a Set node that formats the workflow name, the failing node, the error message and a link to the execution, then a notification send. In each production workflow’s settings, this one is chosen as the Error Workflow.

{
  "nodes": [
    { "name": "On Error", "type": "n8n-nodes-base.errorTrigger", "parameters": {} },
    {
      "name": "Format",
      "type": "n8n-nodes-base.set",
      "parameters": {
        "values": {
          "string": [
            { "name": "msg", "value": "={{ $json.workflow.name }} failed at {{ $json.execution.lastNodeExecuted }}: {{ $json.execution.error.message }}" }
          ]
        }
      }
    }
  ]
}

Cost. It runs once per failure, so a good month is close to free and a bad month is the one where you’re glad you paid for it.

Failure history. This one never crashed. The problem was that it had nothing to say about the failures that mattered most. The Error Trigger only fires when a node throws an error. It stays quiet when a run finishes green but posts an empty caption, writes zero rows, or sends a request to a dead Buffer seat. That kind of quiet failure is the most dangerous kind in an automated operation, so I added a nightly delivery audit that checks whether the output actually showed up on each platform. Building error alerts for failed workflows covers the trigger side. When a successful run delivered nothing covers the other side.

Project 4: the daily brief

Purpose. Every trading day I publish a plain-English write-up of what my paper-trading desk did: the trades, the losses, and what the rules did and why. A share line goes out to X and LinkedIn. It’s a journal of fake-money trades written in past tense. It is a lab, not a tip sheet, and it never tells anyone what to do.

Nodes. Schedule Trigger set after the market close, an HTTP Request that pulls the desk’s state, a Code node that turns the fills into a summary a person can read, a Claude API call that writes the brief from that summary, a writeback that publishes it, and a step that hands off the share line. The Code node does more of the work than anything else here. Raw fills sent straight to a model produce mush. Pre-computed facts sent to a model produce a brief.

Cost. About 21 executions a month, one per trading day. The Claude call is the main cost, and keeping the prompt small (summary only, never the raw tape) keeps that cost under control. The Claude-in-n8n walkthrough shows how that call is put together.

Failure history. The brief taught me how much the support workflows around it actually cost. Several small n8n jobs mirror state like analytics and desk data into the repo so the brief and the site can read it. They used to run every 30 minutes. Each mirror commit to main made the hosting provider spin up a build container just to decide to skip the build, and each of those checks cost about a minute. On 2026-07-27 there were 114 commits, 88 of them mirror refreshes, and they burned through a full billing cycle of build credits in a few hours. I changed three things. The cadences dropped to 180, 240 and 360 minutes, which cut commits from 96 a day to 18. Every automated commit now carries [skip ci], so the provider skips it before starting a container. And the site deploys once a day in a single rollup. Count how often a scheduled workflow writes, not only how often it runs. That cost doesn’t appear on the n8n invoice at all. It appears on the bill from whatever service receives the write. The full brief build is in how I build the daily brief every morning.

Project 5: the video publish chain

Purpose. A daily video goes out around 1pm, and a trading recap video around 5pm, on all five platforms.

Nodes. For X, Instagram and TikTok, the video goes through the same Buffer pipeline as Project 1, with captions written for each platform. The voice track comes from ElevenLabs earlier in the production chain. YouTube and LinkedIn are posted by their own scripts, because each needs an API the Buffer seat doesn’t cover.

Cost. Two video drops a day is about 60 n8n executions a month, which is a small number. The real costs are ElevenLabs characters and video generation, and they are much larger than the n8n bill. My ElevenLabs pricing breakdown explains how that meter works.

Failure history. This one was a timing bug. The static images are generated inside the n8n Buffer workflow, and the only way they reach LinkedIn and YouTube is the git writeback. The first version assumed a fixed gap: wait N minutes, then the image will be there. On slow days it wasn’t there yet, and the other publishers went ahead without it. They now wait for the file to actually exist instead of trusting a timer, and the nightly delivery audit checks that the image arrived everywhere. There are two lessons in that. When two systems share a file, sequence them on the file existing, not on the clock. And when an n8n project hands work to something outside n8n, n8n can no longer see what happens next, so you need a check of your own on the far side. The YouTube end is covered in how the daily video auto-publishes.

What do these five n8n projects have in common?

Taken together, the five projects show the same pattern. None of them broke because n8n failed. They broke at the edges: a caller that retried, a seat that had been reassigned, a commit that triggered a build, a file that arrived late, a run that finished green with nothing in it. The workflows were fine and the boundaries between systems were not.

When I was choosing n8n projects to build, what worked was building one end to end and then spending twice as long on how it could fail. I replied to webhooks right away. I deduped on event IDs. I set one error workflow for everything. I gave each platform one owner. I counted every write a schedule made, not just every run. And I checked delivery at the far end, because n8n only knows what n8n did.

If you want the actual prompt and config files behind these pipelines, not just the diagrams, they’re in the fleet files. One email unlocks them, and they’re the same files this operation runs on.

If one of these five sounds like a job you’d rather not build at 2am, we can wire it up for you.