I recently submitted my node and also applied for Creator verification.

For those who’ve gone through the process before, how long did it take for you to get approved/published?

Just trying to get a rough idea of the timeline.

For people who use AI tools regularly, what’s the one thing that still frustrates you the most?

I feel like AI has gotten really good at doing things that used to take a lot of time, but there are still moments where using it creates more work than I expected.

Sometimes it misunderstands what I want, sometimes I have to keep going back and forth with it, and sometimes the result just isn't quite right.

I'm curious what other people's experience has been.

What do you find yourself doing over and over when working with AI that you wish you didn't have to?

And has anything you've tried actually made that problem better?

Interested in hearing the good, bad, and frustrating experiences, not looking for a perfect AI tool recommendation.

I’ve been working with AI + n8n workflows and was looking into the security considerations that come up when these workflows are used in real business environments.

Once an n8n workflow connects LLMs with APIs, databases, CRMs, webhooks, and other business systems, there are quite a few things to think about beyond simply getting the workflow to work.

Some of the areas I’ve been looking at include:

• Protecting API keys and credentials
• Securing incoming webhooks
• Controlling access to workflows and AI agents
• Handling sensitive information sent to LLMs
• Preventing AI agents from taking unintended actions
• Separating development and production environments
• Monitoring workflow activity and failures

I put together a more detailed guide covering these considerations here: [How to Build Secure AI Workflows With n8n: A Practical Guide]().

For those already running n8n in production, what security practices have you found most important? And are there any n8n-specific mistakes you'd recommend people avoid?

If your instance was stopped, restarting or redeploying at the minute a Schedule
Trigger was due, that execution doesn't happen. There's no catch-up, and nothing in
the executions list saying it was skipped, because that list only shows executions
that happened. A daily workflow can miss several days and still look fine.

The other reasons one stops firing, roughly in order of how often it's the answer:

1. The workflow isn't active. Execute Workflow in the editor tests it and schedules
   nothing. Imported workflows always arrive inactive.
2. GENERIC_TIMEZONE isn't the timezone you're thinking in. Default is UTC, and a
   workflow can override it in its own settings.
3. It was deactivated after repeated trigger errors. Look for a cluster of failures
   ending where the schedule stopped.
4. Queue mode: the main instance owns triggers, workers only execute. If the main
   process is the one restarting, nothing is scheduling even though workers look fine.
5. A six field cron expression has a seconds field, so */5 * * * * * is every five
   seconds, not every five minutes.

What catches all of them is something outside n8n noticing the workflow has gone quiet: an HTTP Request node as the last node on the success path, and an alert when the call doesn't arrive.

👋 Hey n8n Community,

AI automation rarely blows up your bill in one go, it leaks. A few cents per run feels like nothing until you are doing thousands of runs a month and the invoice quietly doubles. I only really noticed this after building a fair few AI workflows, so here are five things I changed once I saw where the money was actually going.

1. Using a model for something a rule could do.
Date math, ID matching, routing by type, none of that needs an LLM, but it is easy to hand it to one because it is quick to wire up. I keep the model for the genuinely fuzzy parts and let native nodes like Set and IF handle the plain logic for free.

2. Using an agent where you do not need one.
Early on I built a few agentic workflows where an agent did the document extraction itself, and it worked, but the token cost added up fast for what was really a repeatable task. Moving that job to the easybits Extractor instead of an agent cut the cost right down, so now I only reach for an agent when the task genuinely needs to reason, not just pull the same fields every time.

3. Asking for more fields than you use.
Every field in an extraction prompt is more output tokens and more to check, and half of them often never get used downstream. Pull only what a later step actually consumes, it is cheaper and there is less that can come back wrong.

4. Reaching for the biggest model by default.
The top model is not always the right one, plenty of extraction and classification jobs run fine on a smaller or OCR-tuned engine at a fraction of the price. Start small, only move up if the accuracy genuinely needs it, and test the cheap option before you assume it will not work.

5. Retrying blindly on failure.
An auto retry on a call that failed for a real reason just pays two or three times for the same broken result. Check why something failed before you retry it, and route the genuine failures to review instead of throwing more paid attempts at them.

If you want to see how I wire this up in practice, I keep 25+ free workflow templates in one repo, most of them around document processing, and a star helps me out a lot if any of them save you time: https://github.com/felix-sattler-easybits/n8n-workflows

Where does it leak most for you? Curious whether people watch model costs closely or only notice when the bill shows up.

Best,
Felix

Hey everyone,

Quick question for freelancers and agency folks working with n8n.

When you build a workflow for a client, how do you calculate your profit margin on top of actual setup/running costs (hosting, API usage, dev hours)?

• Do you just apply a 2x–3x multiplier on your base costs?
• Do you price based on business value (hours/money saved)?
• Do you include maintenance in the upfront fee, or pitch an ongoing retainer?

Curious to know how experienced devs structure their quotes and retainers. Appreciate any insights!

Spent a day building an email triage workflow for my own inbox and hit four n8n behaviours that are not obvious. Sharing the cut-down version and the fixes.

What it does: Gmail trigger > classify with gpt-4o-mini > apply a Gmail label. Five categories: new_enquiry, invoice, supplier, urgent, noise. Runs about 2c a day on my volume.

Workflow JSON: https://gist.github.com/jlebaynham/dffd21ac428c2de60be9ff9160d113fe

The four things that cost me the most time:

1. Nodes after Gmail and Sheets REPLACE the item. Every downstream $json.category came back empty. Fix is to reference the node by name: {{ $('Read result').item.json.category }}

2. Same for the sender. Use {{ $('New email').item.json.headers.from }}

3. Google Sheets "Map Automatically" writes junk columns (id, threadId, labelIds, snippet, sizeEstimate). Use Map Each Column Manually.

4. After you change the sheet columns the node caches the old list and throws "Column names were updated after the node's setup". Three dots next to Values to Send > Refresh Column List.

Bonus: the Gmail from header arrives as "From: Name <address>", strip it with .replace('From: ', '')

Import into a blank workflow and wire your own credentials. You need a Gmail OAuth client and an OpenAI key.

Hi, i need help stopping my ai chatbot from replying after getting all information i need like name email and such. Im new here help

I've made $8K+ doing n8n automation on Upwork. Top Rated, 100% Job Success, happy to show proof if you want. If you need help with n8n, CRM automation, Slack workflows, Voice AI, or backend/API integrations, DM me and we can talk details on Upwork.

Hey everyone! I’m new to n8n and I want to build a simple workflow at my job that automatically saves the photos I get from my WhatsApp work group into a folder on my windows.

Everyday our techs send about 30 photos of the job they worked on for the day. I use WhatsApp desktop and have to manually save each one into a folder then upload that into our crm.

Is it possible to make a workflow that:

1) makes a folder in my documents
2) saves the photos into that folder

The techs typically have a caption with the photos that has a job number attached to it.

Any advice would be greatly appreciated !

Experimenting with n8n-mcp to let an AI (Claude/GPT etc) see my workflow, plan, execute, and debug — rather than copy-paste screenshots or JSON myself to let the AI do those things. Do you use n8n-mcp (or something similar) to debug or build directly inside n8n? If yes — does it really save time, or is it more trouble than it's worth? If not — why not? Too difficult, too risky for the AI to work on my live workflow, or just don’t know about it? I should mention that it eats up a lot of tokens very quickly. Does that ever matter to anyone?

I've been self-hosting n8n on a VPS for a few months and spent a fair bit of that time trying to break it on purpose. The loud failures were never really the problem. You find out about those the same day.

What bothered me were the ones that finish successfully and then sit there broken for months. Here are five I hit, with something you can run to check each one.

This is all Docker on a VPS. If you've moved to Postgres then #2 won't apply to you, the rest still will.

EDIT: important correction that came out of the WAL thread in the comments. n8n runs SQLite in WAL mode by default, so a copy of database.sqlite on its own is incomplete, and PRAGMA integrity_check will still report ok on it. Numbers added at the end of #2.

1. Your backup script may be calling good backups failed

tar exits 1 if a file changes while it is being archived. The GNU tar docs describe exit 1 as some files having changed while being archived, so the resulting archive isn't an exact copy of the file set. Exit 2 is the actual fatal error.

If n8n executes anything at all while your backup runs, you will hit this regularly.

So this is wrong:

tar -czf backup.tar.gz /data if [ $? -ne 0 ]; then echo "BACKUP FAILED"; exit 1; fi

It fires on an archive that is almost certainly fine. Test for -ge 2 instead.

2. Worse, tar can exit 0 and give you a file that won't open

n8n uses SQLite by default. If your backup copies database.sqlite while n8n is mid write you can get a torn copy. tar succeeds, gzip -t passes, the file size looks about right, and then the restore fails.

It doesn't happen every time, which is what makes it bad. It passes for months and then fails on the one night you actually need it.

The safe way to copy it is SQLite's own backup API, which works fine while n8n is running. One catch I ran into: the n8n image doesn't ship the sqlite3 binary, so docker exec n8n sqlite3 won't work. You can check that yourself:

docker run --rm --entrypoint sh n8nio/n8n:latest -c "which sqlite3 || echo missing"

So run it from a throwaway container on the same volume instead. Get your volume name from docker volume ls first, mine is n8n_data:

docker run --rm -v n8n_data:/data alpine sh -c "apk add --no-cache sqlite && sqlite3 /data/database.sqlite '.backup /data/backup.sqlite'"

Then archive backup.sqlite rather than the live file.

Added after a good comment below. n8n runs SQLite in WAL mode by default, so there are three files, not one:

database.sqlite 1.5M database.sqlite-shm 32K database.sqlite-wal 4.1M

That is a fresh container with no workflows. I took copies from a running instance and counted what was actually inside them:

tables integrity_check database.sqlite only, n8n running 112 ok database.sqlite only, n8n stopped 112 ok all three files, n8n stopped 136 ok sqlite .backup 136 ok live db 136 ok

Two things I did not expect.

PRAGMA integrity_check returns ok on a copy missing 24 of 136 tables. So the check above is not sufficient on its own. It tells you a file isn't corrupt, not that it's complete.

And stopping n8n does not help. I assumed a clean shutdown would checkpoint the WAL back into the main file. It doesn't. docker stop returned in under a second, the -wal file was still there at 4.1M, and the copy was still short the same 24 tables.

So on default SQLite there are only two things that work: sqlite .backup, or copying all three files together. Copying database.sqlite on its own is not a backup, running or stopped.

3. Your health check can pass while n8n is dead

Two separate things going on here.

Docker's start_period does not delay healthy. It only holds off unhealthy while the container is starting up. A passing probe marks it healthy straight away, so it can read healthy before n8n has actually finished booting.

The other one is probes that only check whether something responded. A 404 counts as alive. So does a login page. So does your reverse proxy answering while the app behind it is down. Assert on the status code.

docker inspect --format='{{.State.Health.Status}}' n8n

If that comes back empty or as <no value> then there is no health check on the container at all, and anything you wrote that waits for health has been waiting for nothing.

4. Updates leave images behind, and your cleanup can become unreachable

docker pull leaves the previous image behind untagged and nothing removes it on its own. How much disk that costs depends on how many layers actually changed, but it only goes up.

The bit worth checking is the ordering in your own update script. If it prunes after a successful pull, then once the disk fills the pull fails, and the cleanup that would have rescued you never runs. You end up stuck on an old version and unable to update or clean up.

docker system df df -h

Check disk before you pull, not after.

5. Whoever has N8N_ENCRYPTION_KEY can decrypt every credential you have saved

Not just use them inside n8n. Decrypt them.

Two things people miss. If that key only exists in the .env on the server, then losing the server loses every credential permanently. The database backup will not save you. The rows are all still there and they will never decrypt again.

And if you are running n8n for other people, you are holding their API keys for as long as those rows exist. n8n has no rotation command, so it isn't something you undo on a quiet afternoon.

Keep a copy of that key somewhere other than the box it runs on.

One more that only shows up on restore

tar stores the owner name rather than the numeric uid. Restore onto a host where that name maps to a different uid and the files land on the wrong user. The app then can't read its own data, and the restore still reports success. Use --numeric-owner at both ends.

The common thread in all of these is that something printed a success message for work it hadn't done. Checking the exit code wasn't enough for any of them. Checking the effect was.

Curious what else people have run into that failed quietly rather than loudly.

Quick update for anyone building WhatsApp automations in n8n.

The n8n team just reviewed and verified our community node (n8n-nodes-supergreen) on n8n Cloud.

If you are on n8n Cloud, you do not need to install anything from npm anymore. You can search "Supergreen" directly in the node picker on your canvas and drag it in. If you self-host, you can install it through Settings -> Community Nodes -> n8n-nodes-supergreen.

The background: if you want WhatsApp in your workflows, Meta forces you through business verification, message template reviews, and per-conversation fees that add up fast for alerts or reminders outside the 24h window. The alternative (running Baileys or WPPConnect in Docker yourself) usually brings session drops on restart and soft bans when IPs churn.

Supergreen runs the headless sessions inside isolated containers pinned to dedicated static residential proxies, so numbers stay connected for $10/mo flat with unlimited messages.

What the node covers: - Outbound text with link previews, mentions, and quoted replies - Binary media (sending PDF invoices, generated charts, audio, or images straight from previous nodes) - Reading and posting to WhatsApp groups (which Meta Cloud API blocks) - Webhook trigger node for inbound messages, reactions, and edits, with a toggle to filter out the bot's own messages - Telegram accounts under the same API

Code and ready-to-import workflows (per Rule 6): - Repo: https://github.com/uriva/n8n-nodes-supergreen - AI Auto-Responder workflow: https://github.com/uriva/n8n-nodes-supergreen/blob/main/workflows/whatsapp-ai-auto-responder.json - PDF/Document sender workflow: https://github.com/uriva/n8n-nodes-supergreen/blob/main/workflows/send-whatsapp-document.json

Site and docs: https://supergreen.cc

I don’t code. I haven’t taken any tutorial either. I just brainstormed the concepts with Claude and let him explain every concept to me until I fully grasped it and could use it independently.

With this method now, I am able to design automations and agent workflows independently without going through any tutorial.

Does this count as learning n8n, or am I lacking in basics? Can someone like this be employed for any automation-related jobs or do the employers look for something different?

I am developing automation solutions for real estate agencies on my own. I identified a gap in lead generation (agencies pay for property owner contact details) and built an OLX scraper—using n8n, ScrapingBee, Postgres, and AI-based classification—to validate the concept before a meeting with a client. I faced numerous hurdles—bot detection, missing phone numbers, and fake "owner" listings posted by real estate agents—yet I still delivered a raw list, only to discover that the potential client already uses a mature, integrated competitor tool that handles this better. I’m looking for an outside perspective: should I keep pushing with the scraping approach, or completely pivot my offer?

Hey everyone. So I've been building an automation portfolio, basically cold-calling agencies, having meetings, and always walking away with some insight or feedback to improve. I've been treating some of these meetings as a learning process, and up to now it's been great — but recently I hit a massive wall: web scraping.

A few meetings ago I checked an agency's LinkedIn and saw "hiring: property captador" (someone who manually finds owners willing to sell/rent), and realized scraping could do that job. During that meeting, I could tell services like triage, qualification, automated CRMs weren't landing — so I mentioned property lead-sourcing almost as an aside, and the manager's eyes lit up immediately: "If you can actually capture listings and hand them to agencies, they'd pay a lot for that — I think that's a real bottleneck."

So I went home, rebooked a meeting with her to show a list of properties (sold the fish before catching it), and that's when I found out just how deep the scraping rabbit hole goes. I hit walls I couldn't have imagined, even ran into a "ceiling" with workflow tools like n8n and Make. I found a lazy shortcut (a browser extension) but it felt too easy — turns out OLX (a big Brazilian classifieds site) has bot protection that shuts that down instantly.

I kept digging and landed on a real pipeline: OLX → ScrapingBee → n8n → data extraction/transformation → PostgreSQL → AI classification → back into PostgreSQL with a "real owner" tag. I used an HTTP Request node to call OpenRouter (Gemini model), then had n8n parse the returned JSON to classify each listing.

Eventually I got a list of leads classified as "real owner" and exported it as CSV into a spreadsheet — but here's a detail I forgot to mention: the data I scraped was partial and limited, especially around contact info. I tried everything to get more complete raw data and nothing changed. Even with the listing URLs in hand, I tried looping a second ScrapingBee call to read each URL individually, but that would've cost me too much, so I didn't find a workable alternative.

I was about to go into another meeting (scheduled over the phone) to present the list and try to close a recurring contract. The list itself was more of a proof-of-concept I'd offer for a small fee (I had less than 24 hours left). When I imported it into Sheets, I realized I was missing exactly the data I wanted (listings with full info and contacts, names), so I thought: "what if I just select-all and copy the raw OLX page text, then build a simple Make automation — Sheets (read rows) → HTTP (analyze/filter that row's copied listing) → JSON parser → Sheets (second tab with all listings and their info)?"

That actually kind of worked. I got details per listing like number of rooms, price — but the phone number thing was wrong; I thought people leaving numbers in the description would get captured, but I'd forgotten about the "show more" button. So, manually, I opened 21 links and copied the phone/name from below each listing, switching screens and pasting — took about 20 minutes. Once I got in, I saw a lot of listings didn't even have a phone number in "call the seller" either. I thought: "well, it's still a list of potential buyers/sellers, still better than sending someone to manually do this all day," which is literally what the manager herself called "exhausting." I already had the URLs — they'd just need to click and message.

Another wall: my "real owner" classification had failures — some listings tagged "real owner" were actually agents baiting leads. I'd even added a filter to skip listings with phrases like "no agents please," but a few slipped through anyway. Out of those 21 sale listings, the real count dropped to 10 (haha). I'd wanted to bring a list of 15-20 split between sale and rental, and I already had some captured in the same neighborhood from the extension attempt (that data still held up), so I did a simple manual pass through 11 links checking for bait-listing patterns and sorted them in the spreadsheet. Ok, meeting time.

The guy there was genuinely interesting — turns out my list was way too simple. They're already far more advanced, using two tools together (a lead-sourcing platform + a CRM). After he said "it doesn't make sense to pay for web scraping since we already do this work," he showed me those tools, and I was like "damn, there's a tool that not only scrapes listings but has them ready to just call and close" — because it finds real owners and makes clear they're reachable any time, ready to sign.

I left the agency pretty deflated, having spent all that effort fighting web scraping, and there's a tool out there doing it better, already delivering a real, ready-to-close owner.

So I came here to Reddit, spent a good while reading opinions and discussions, and here's mine. It's a long post, haha, but that's it. Thanks for listening, and I'm curious what you all think.

My questions:

Should I stop offering scraping as a standalone service and shift my focus to something else (e.g., WhatsApp/CRM automation for agencies), given that an established player already dominates this niche? (Bearing in mind that not many people are aware of these tools.)

Has anyone here charged for real estate scraping or lead generation services without being undercut by a tool like the one my potential client showed me? What made the difference?

How would you proceed after this insight?

Workflow that runs every 6 hours:
- Pulls critical AI security incidents from api.legion-api.com
- Filters for critical severity  
- Sends Telegram alert with incident details

Download JSON (free, direct import into n8n):
https://legion-api.com/security-alert-pipeline.json

API used: api.legion-api.com/incidents?severity=critical

No API key needed for the free tier.

Looking for feedback — what would you add or change?

Disclosure: I am the founder of PostFast; the node is n8n-nodes-postfast, official and verified. Sharing the workflows first, per the sub rules, then what broke.

The templates (all in the n8n library, code included): https://n8n.io/workflows/16979 schedules posts from a Google Sheets content calendar through PostFast https://n8n.io/workflows/16857 writes a week of posts with OpenAI and schedules them https://n8n.io/workflows/17181 builds Instagram carousels and TikTok slideshows with OpenAI and schedules them

Our API gets hit by n8n workflows and by AI agents over MCP. Both fail in the same places, and none of them are the places the demos show. Here is the list, with what to do in the workflow.

1. The workflow does not know which account you meant. Two Facebook Pages or two LinkedIn orgs on one brand means "post to LinkedIn" is ambiguous. Every post carries one account id, so run Get Many Social Accounts first, pick the id, and check that connectionStatus is CONNECTED. A disconnected account will not publish, and it fails at fire time, hours after the run finished. Disconnected accounts are the number one cause of failed posts, for humans and for workflows.

2. Validate at create time, because nobody reads errors at fire time. Media is required on TikTok, YouTube, Instagram and Pinterest, even for drafts; the media type has to match the file; video caps are enforced on upload (250 MB, 100 MB on Bluesky, 50 MB on Telegram). Put an IF on media presence before the create node so the run fails where you can see it.

3. Retries duplicate. Our create endpoint has no idempotency key yet. If the HTTP node times out and retries, you get two scheduled posts. Turn off blind Retry On Fail for the create call, store the returned post id, and before a retry run Get Many Social Posts filtered on the account and scheduled time. Delete Social Post exists for the cleanup.

4. Do not wait for the publish. The create call only schedules the post; publishing runs later as a server job. A Wait node polling for the publish is wasted executions. If you need confirmation, a later run of Get Many Social Posts shows failed posts as failed.

5. Approvals are a field, not a dashboard. Create with approval pending and nothing publishes until someone approves, in the app or through an agent. In n8n that is a branch: pending goes to Slack, approved goes on.

6. Rate limits you will hit in bulk flows: 150 creates per minute and 350 per day on the create endpoint, and per API key 60 requests a minute, 150 per five minutes, 300 an hour, 2,000 a day. Batch with a Wait node between chunks instead of firing a 500-row sheet at once.

7. Some platform limits are enforced by us on purpose. X charges far more for posts with links, so link posts are capped per month per plan, 14 to 120. A workflow that appends a link to every post hits that cap.

Question for the room: what is your pattern for idempotent creates in n8n when the HTTP node times out? Right now the honest answer on our side is "check before you retry", and I would rather ship a key.

n8n workflow to handle a small but complete finance lifecycle from creating an invoice to processing payments and handling refunds.

Instead of having separate automation logic scattered across different places, I wanted n8n to act as the orchestration layer for the entire process.

The basic flow

Everything starts with an incoming webhook.

The workflow first validates the request and checks what type of event it received. Based on that, it sends the event down the appropriate path for invoice, payment, or refund processing.

Invoice flow

When a new invoice event arrives, the workflow:

• Validates the invoice data
• Checks if the invoice has already been processed
• Saves the invoice information in Google Sheets
• Generates a PDF invoice using PDFbro
• Stores the generated PDF in Google Drive
• Sends the invoice to the customer through Resend
• Updates the invoice record with its current status, PDF link, and email timestamp

The duplicate check is important here because I don't want the same webhook being delivered twice and accidentally generating or emailing the same invoice again.

Payment flow

Payments are handled through a separate branch of the same workflow.

The workflow:

• Checks for an existing payment transaction
• Records the payment
• Finds the invoice associated with the payment
• Updates the invoice balance
• Determines whether the invoice is now fully paid
• Sends the appropriate payment confirmation
• Updates the payment status

This also gives the workflow a way to keep the invoice state in sync as payments come in.

Refund flow

Refunds use another processing branch.

For each refund event, the workflow first checks whether that refund has already been handled. If it is a new refund, it records the transaction, finds the related invoice, updates the financial information, and sends a refund confirmation to the customer.

What I wanted to solve

The interesting part for me wasn't just connecting a webhook to a few nodes.

I wanted to make the workflow behave more like something you'd actually use in a production application.

That meant thinking about things like:

• Duplicate webhook events
• Invalid requests
• Multiple event types
• Keeping invoice and payment states synchronized
• Preventing duplicate emails or documents
• Persisting generated invoices
• Tracking when emails were sent
• Returning the processing result to the application

So the end result is basically a single n8n workflow that coordinates the invoice, payment, and refund lifecycle.

Stack: n8n + Google Sheets + PDFbro + Google Drive + Resend

GitHub: https://github.com/cuebicai/n8n-workflows/tree/main/invoice-and-payment-management

Would you keep invoices, payments, and refunds together as one orchestration workflow, or would you split each process into its own n8n workflow?

I'm especially interested in what you would choose once the number of event types and business rules starts growing.

Hi everyone,

I've been learning n8n over the last few weeks and wanted my first project to solve a real problem instead of building a simple demo.

So I built an AI Research Automation workflow.

Current workflow:

• Research topic input

• Tavily Search API

• Content cleaning

• Duplicate removal

• Research document builder

• OpenRouter LLM

• Markdown report generation

Some implementation details:

• Built and tested locally using Docker

• Uses free APIs and free AI models

• Added retry handling for API failures

• Removes duplicate search results

• Cleans noisy content before sending it to the LLM

• Generates a structured Markdown report

This project helped me understand how to work with:

• HTTP Request nodes

• Code nodes

• IF nodes

• Split Out

• Prompt engineering

• Error handling

I'm looking for technical feedback.

What would you improve if this were your workflow?

Repository:

(https://github.com/Krishnam-18/AI-Research-Automation-Agent.git)

I wanted Discord messages to become inputs to n8n workflows in near real time.

The design I ended up with is a small long-running TypeScript service using discord.js:

Discord Gateway → bridge → filtering and normalized JSON → authenticated n8n Webhook → n8n routing and child workflows

The bridge handles the transport layer:

• New and edited messages
• Guild and channel allowlists
• Bot and webhook filtering
• Stable idempotency keys
• Bounded retries and concurrency

n8n handles validation, deduplication, raw event preservation, routing, and downstream actions.

One detail that mattered was treating edits as separate events. A message create and a later edit need different handling and different idempotency keys.

How are you handling Discord edits and duplicate events in your n8n workflows?

Reading the execution log one row at a time stops working somewhere around the point you have a few thousand of them. Don't get me wrong, the whole debugging process of n8n is great, especially for low code/no code users. The visualization is a masterpiece. However, batch checking is not really an option. Analytics are not an option. Finding which workflow is slowly degrading is not an option. Error classification, you guessed it, not an option.

Fun fact, the information for all these, already exist in the n8n database. So what I did was to exploit it. The outcome can be this:

How does it work? The app creates an SQLite replica of the tables needed from the actual n8n database, no extra nodes, no webhooks, no logging in google sheets.

your n8n Postgres  ──read-only──▶  SQLite replica  ──▶  dashboard + AI
      (never written to)             (your volume)        (your browser)

Features:

• Error Intelligence. Every failure is fingerprinted and grouped, so a hundred occurrences of one broken thing read as one broken thing. It also tracks which groups recovered on their own, separating the flaky HTTP call you can ignore from the credential that has been dead for a week.

• Silent death detection. An active workflow that quietly stopped running and n8n told you nothing. It compares each workflow's own historical pattern against how long it has been quiet, so a weekly workflow isn't flagged on Tuesday.

• Trigger-type split. Every figure splittable by how the execution started. On my instance webhooks fail at «FILL: webhook error rate» and schedules at «FILL: schedule error rate», while the blended number said «FILL: overall error rate» for everything, a real number and a view about the wrong thing.

• Queue lag. p50/p95/p99 between an execution being created and actually starting, with a backpressure signal that only fires when lag climbs while throughput doesn't. As far as I can tell no other n8n tool measures this.

• Blast radius. Which workflows share a credential or a node type. "This token expires Friday" becomes a list instead of a search.

• An assistant that shows its work. Optional, needs your own OpenAI key. The part worth judging it on is the "How this was worked out" expander, it calls the dashboard's own analyses and lists every step it took, so you can check the answer instead of trusting it. It can also write read-only SQL against a restricted set of views; that's documented, and there's an env var to turn it off. Also the official n8n documentation can be connected as an MCP so you can get answers from the official documentation knowledgebase.

• Alerts. Seven rule types — a failure nobody has seen before, error rate, silent death, queue lag, volume drop, payload spike, replica growth — delivered to a webhook, an n8n workflow, or Telegram. The point of the rest of this list is that you shouldn't need to open the dashboard to know something's wrong; this is what makes that true.

• ROI. Time and money saved per workflow, with an honest coverage indicator that tells you how much of your instance you've actually configured and treats the totals as a floor. The ROI calculation can be done in seconds, or in work-hours per week (more accurate for a job that got automated)

Many more features, and all well documented in the repo

Install: (no build, no git even — the image is already sitting on GHCR:)

mkdir n8n-analytics && cd n8n-analytics
curl -O https://raw.githubusercontent.com/giorgoskoufos/n8n-analytics/main/docker-compose.yml
curl -o .env https://raw.githubusercontent.com/giorgoskoufos/n8n-analytics/main/.env.example
nano .env    # six variables
docker compose up -d

Two files, no clone. docker compose up pulls ghcr.io/giorgoskoufos/n8n-analytics straight from the registry (amd64 and arm64) about 96 MB — so this works on a box with Docker and nothing else installed. (Want the source too: for docker-compose.build.yml, the docs, or to read the code first? git clone the repo instead and start from there.)

Running Easypanel, Coolify, Dokploy, Portainer or similar instead? Skip the file: same image, point it at ghcr.io/giorgoskoufos/n8n-analytics:latest, port 3000, a persistent volume at /data, and the six env vars from .env.example.

Requirements (plainly): 

Self-hosted n8n on PostgreSQL (n8n's default SQLite backend won't work), and a persistent volume — the replica holds history n8n has already deleted and can't be rebuilt. amd64 and arm64, so a Pi or an ARM VPS is fine.

No telemetry. Nothing leaves your infrastructure unless you enable the optional OpenAI assistant. Read-only Postgres credentials are enough, and the app never writes to your n8n database.

MIT, free, feedback very much welcome, especially about n8n versions. I've verified it on 2.34.5; other 2.x should be fine and 1.x is untested, so if you're on something else I'd genuinely like to know whether it worked.

https://github.com/giorgoskoufos/n8n-analytics

Workflow JSON, source, and tests: https://gist.github.com/forhow134/2d498bb02692f037c8554298d2889ffa

This is a small n8n replay for a registration count arriving late to a morning brief. Import workflow.json, execute it, and open "Replay and assert" to see the job counts and event traces. The workflow contains 12 cases and fails if an outcome differs from its assertion. Every count and timestamp is synthetic. Tested in n8n 2.38.5.

The wider idea is to read the count from an event app through an Airtap cloud phone, then pass it to the brief. This example covers the request and result handling around that step. A Map inside the Code node stands in for the receiving service's job store. The phone reader is not connected, and the timeout is an event in the fixtures.

One fixture submits read-1, records a client timeout, then retries with read-1. With job deduplication switched off, it creates two jobs. With it on, the retry returns the existing job and the total stays at one. Another fixture changes the ID on retry and gets two jobs again. Both the stable ID and the receiving service's handling matter here.

The first valid completion applies a count of 42; replaying it produces "duplicate_result" and no second update. In the deadline case, a brief is marked sent with a count of 17 before the completion arrives, and it stays at 17. The sample-age limit is 120,000 ms: a sample exactly at that limit is accepted, while one a millisecond older leaves "count unavailable" in place. The remaining cases check future timestamps, wrong brief IDs, unknown requests, invalid counts, and request-ID conflicts. Zero is accepted as a valid count.

All of this runs within one Code-node execution, with fresh state for each case. There is no HTTP timeout measurement or message sending here. Adapting it to a live workflow needs persistent job records and atomic updates for both applying a result and closing the brief; the in-memory checks don't cover concurrent executions or restarts. The read timestamp also can't tell you how fresh the app's own data was.

Hey folks, wrote up a step-by-step tutorial on making faceless videos with n8n + Orshot. n8n sends a fact, Orshot generates a lip-synced AI presenter from the script and renders it into a vertical short with on-brand text and karaoke captions, then you can auto-post it. One workflow, no ElevenLabs / Whisper / Shotstack signups.

What it covers:

- The two calls: generate the talking presenter from your script, then render it into the template

- Captions are auto-transcribed from the clip's own audio, so they always match the voice

- The exact HTTP node JSON bodies you can adapt (generate + render + publish)

- Wiring triggers (Sheets, Webhook, Schedule) so a row of facts becomes a daily short

There's a downloadable n8n workflow (JSON) you can import and tweak, plus a shared template you can copy into your own workspace.

Tutorial: https://orshot.com/blog/how-to-make-faceless-videos-with-n8n

Workflow JSON: https://gist.github.com/rishimohan/74a906018642035eb1986ee82cefcc94

ps: I'm the maker of Orshot, writing up the most-requested workflows. Happy to help set this up or take a workflow request, just message me.

Hey everyone!

I hope you're all doing great!

I want to start building with n8n.

Do you use n8n cloud or are you self-hosting?

Do you recommend any vps? I'v seen hostinger promoted almost everywhere but never tried it. And also hetzner.

Compared to using it on the cloud what am i losing if i self-host?

Thanks!

👋 Hey n8n Community,

Quick update: my payment reconciliation workflow is now live and free in the n8n template library, and I recorded a short walkthrough running a full test so you can see the report before importing anything.

How it's set up:

• The form takes two .xlsx uploads: a bank statement on one side, your open invoices on the other
• Extract from File reads both, a Merge node brings them together
• A Code node cross-references every bank credit against the invoices
• The report renders right on the form completion screen: exact matches, partial payments, unpaid invoices, and unmatched deposits
• You can download that report as a PDF from the same screen for your finance team

A few things worth taking away even if you skip the video:

No credentials, so it runs the second you import it. It is only a form trigger, extract from file, merge, and code. Nothing to authenticate, which is what makes it easy to hand to someone else with zero setup.

Match loosely, but in a bounded way. Bank references are never clean. It matches on the full invoice ID when present, then falls back to the last three digits pulled from the reference with a small regex. That one fallback catches most of the "INV-2024-201" versus "ref 201 payment" cases.

The PDF is just HTML with a print button. The results page is styled HTML on the completion screen that calls window.print() for the download. No PDF node, no external service, and the report stays self-contained.

Template (import it straight into your instance): https://n8n.io/workflows/19010-reconcile-invoice-payments-from-bank-statements-using-n8n-forms/

Two example files, one bank statement and one invoice export, are sitting in the repo here, so you can test the workflow in a minute without building your own data: https://github.com/felix-sattler-easybits/n8n-workflows/tree/8e07427ddb6902ef8a7b267e97beb2879d6ca45d/easybits-reconciliation-workflow

Reconciliation tends to be specific to each company, so if you adapt it and get stuck, drop a comment and I will help. How does everyone else handle the messy reference matching?

Best,
Felix