Building automation got cheap. Owning it did not.

A founder showed me an automation last month that had been quietly doing nothing for eleven days.

It ran on schedule. The dashboard was green. Every execution was marked successful. It was pulling leads from a form, enriching them, and writing them to a sheet, and somewhere in the middle a field had been renamed, so it had been writing empty rows since the first week of the month.

Nobody noticed because nothing broke. It failed politely.

That is the state of automation for small businesses in 2026, and it is worth being precise about why, because the usual explanation is wrong. This is rarely a story about people picking the wrong tool.

Building automation got cheap. Owning it did not. Almost nobody budgeted for the second part.

First, How Cheap Building Actually Got

You need the scale of this to understand the rest.

The n8n numbers

Jan Oberhauser started n8n around 2019 as a side project in Berlin. In October 2025 it raised 180 million dollars at a 2.5 billion dollar valuation, led by Accel with Nvidia’s venture arm participating.

Seven months later, on 12 May 2026, SAP took a strategic stake at a 5.2 billion dollar valuation and agreed to embed n8n inside Joule Studio, its AI agent builder. The valuation had more than doubled in under a year.

n8n says it now has 1.7 million monthly active builders, more than 1,400 enterprise customers, and 162,000 GitHub stars. Those are the company’s own figures and worth treating as such, but the direction is not in dispute.

The part that matters for a small business is the license. You can self-host it for free for internal use. You pay when you host it commercially or embed it in something you sell.

The pricing model that changed the math

This is the detail most founders miss, and it is the one that actually moved the ceiling.

Zapier meters per task, where every action step inside a Zap counts as one task. n8n meters per execution, where a whole workflow run counts as one, however many nodes it passes through.

A five-step workflow triggered a thousand times bills five thousand tasks on one model and one thousand executions on the other.

The cost of a workflow stopped scaling with how carefully you built it.

Under task pricing, adding a validation step, a logging step and a fallback path made the workflow more expensive every time it ran. So people left them out. The pricing was quietly teaching everyone to build fragile things.

Under execution pricing that penalty disappears, and you can add every guard you want for free.

I will say the obvious thing about the dollar comparisons though: the ones in blog posts are mostly invented. Both vendors publish their prices and your own volume is the only number that settles it. Run yours.

What this adds up to

A founder in Kampala with no engineer and no budget can now run the same orchestration layer a Fortune 500 team runs, on a 5 dollar server, with no meaningful limit on how many steps it has.

That is a genuine change and I do not want to undersell it. I run my own lead pipeline this way.

The trouble is that everybody stopped the analysis there.

The Bill Arrives in Three Parts

When the cost of building something falls to nearly zero, the cost does not vanish. It relocates.

It moves to whoever has to notice when the thing breaks, whoever holds the keys it uses, and whoever answers for what it did while nobody was looking.

Here is what each of those costs, with the actual numbers.

Bill One: Silence Is the Default Setting

Two defaults that combine badly

n8n prunes execution data once a run is older than the value of a setting called EXECUTIONS_DATA_MAX_AGE. The default is 336 hours, which is 14 days. It also prunes once total executions pass EXECUTIONS_DATA_PRUNE_MAX_COUNT, which defaults to 10,000.

Separately, error handling is opt-in. You build an Error Trigger workflow, then you attach it to each workflow in that workflow’s settings. A workflow with nothing attached fails into the log and waits to be found.

Put those two together and you get the thing I opened with.

A workflow can fail every single day for two weeks, and the evidence of it expires before anyone goes looking.

On a busy instance the count limit bites sooner. Ten thousand executions is a fortnight for some people and two days for others.

Why green dashboards lie

Most automation platforms report on whether the run completed, because that is the thing the platform can see.

They cannot see whether the run did anything useful. A workflow that writes 400 empty rows completed successfully. A workflow that sends an email with an unrendered variable in the subject line completed successfully. A workflow whose upstream API started returning an empty array completed successfully, very fast, 400 times.

Speed is the tell people miss most often. When a workflow’s average duration drops sharply and nothing about it changed, something upstream stopped returning data.

The fix is embarrassingly small

Build one error workflow. Attach it to everything. It takes an afternoon and most people running n8n in a small business have never done it.

Then add one assertion to any workflow that matters. Not a status check, a content check. If the row count is zero, fail on purpose. If the enrichment returned no company name, fail on purpose. Make it loud.

A workflow that cannot fail is a workflow you cannot trust, because you have never seen it tell you the truth.

And once you have built the alert, break the workflow deliberately while you are watching, to confirm the alert actually arrives. I have lost count of the alerting setups that route to a channel nobody has opened in six months.

The part nobody wants to hear

Change your retention setting before you need it. Thirty days of execution history costs almost nothing in disk and it is the difference between diagnosing a problem and guessing at it.

You will only want this on the day something has gone wrong, and on that day it is already too late to have wanted it.

Bill Two: You Now Hold Every Key in the Business

This is the section I expect to be unpopular, and it is the one I would keep if I could only keep one.

Think about what your automation platform actually stores. The Gmail token. The Stripe key. The database password. The WhatsApp credential. The Google Sheets access. The CRM login.

Your automation tool is not one more app. It is the place where every other key in your business is kept.

Self-hosting means the duty to patch that box is now yours. Here is what that duty looked like over nine months.

November 2025: the unauthenticated file read

n8n patched a flaw in version 1.121.0 and shipped it to everyone on 18 November 2025. Versions 1.65 through 1.120.4 were affected.

An unauthenticated remote attacker could get read access to the underlying filesystem, though only where a workflow contained both a Form Submission trigger and a Form Ending node returning a binary file. Narrow conditions, and n8n published the advisory themselves on 8 January 2026.

That is a vendor behaving well. Note the gap between the fix and the disclosure, because self-hosted users who do not update are exposed in that window without knowing the window exists.

December 2025: the sandbox escape

Pillar Security found a vulnerability on 21 December 2025 and rated it CVSS 10.0, which is the top of the scale.

The first patch, two days later, was incomplete. A bypass was found on Christmas Eve. It was fully fixed in version 2.4.0 and disclosed publicly on 4 February 2026.

What an attacker could do: extract the encryption key from the environment and decrypt every credential stored on the instance. API keys, OAuth tokens, database passwords, all of it.

What an attacker needed: an ordinary authenticated account with permission to create a workflow. The researchers’ own phrasing was that if you can create a workflow, you can own the server.

That is not a hacker-in-a-hoodie threat. That is your contractor’s account, or the intern you onboarded in March and never offboarded.

January 2026: the community nodes

This is the one that should change how you work.

Endor Labs found eight malicious npm packages posing as n8n community integrations. When installed, they showed a legitimate-looking configuration screen that captured your OAuth credentials, then decrypted the tokens already stored on your instance using n8n’s own master key, and sent everything to a remote server.

Targets included Google Ads, Stripe and Salesforce. The eight packages had roughly 27,825 downloads between them, the largest single one at 8,385.

It was the first supply chain campaign aimed specifically at the n8n ecosystem. It will not be the last, because the economics are excellent: one poisoned node reaches every credential on every instance that installs it.

March 2026: the one that is being exploited right now

CVE-2025-68613 is an expression injection flaw rated CVSS 9.9 that leads to remote code execution. It affects versions from 0.211.0 up to the December 2025 patches.

The US Cybersecurity and Infrastructure Security Agency added it to the Known Exploited Vulnerabilities catalog, which is a formal statement that it is being used against real targets, not a theoretical risk.

Shadowserver data reported in early February 2026 counted roughly 24,700 unpatched instances still reachable on the internet.

Twenty-four thousand seven hundred boxes, each holding every credential of whoever set it up, against a flaw with a published patch and confirmed exploitation.

That number is the whole argument of this piece expressed as a single figure. Somebody built the thing. Nobody owned it.

What I am actually saying

None of this makes n8n unusually risky, and I use it daily. Any platform that stores every credential you own, evaluates user-supplied expressions, and accepts third-party plugins has exactly this shape. Zapier and Make carry the same risks with a different party doing the patching.

The honest trade is this. Managed hosting means you pay money and somebody else patches. Self-hosting means you save money and you patch. Both are reasonable. Only one of them is free, and it is not the one people think.

The four things that cost you nothing

Subscribe to your platform’s security advisories and actually read them. n8n publishes theirs.

Update on a schedule you decide in advance, so that patching is a habit and not a reaction.

Treat every community node as code you are running with full access to your credentials. Check the publisher, check the download history, and prefer the built-in node even when it is uglier.

Offboard accounts the week people leave. On a CVSS 10.0 sandbox escape, a stale account with workflow permissions is the whole attack.

Bill Three: Agents Make Both of the Above Worse

More than a few founders are now putting AI agents inside these workflows, and the agent node has become one of the most used building blocks on the platform.

I do this too. It is genuinely useful. It also breaks the assumptions the first two sections relied on.

A deterministic workflow either works or it does not

An agent is a distribution.

Sierra’s tau-bench measures agents on realistic customer service tasks, where success means the final state of the system matches the goal state and the right information reached the user. On 115 retail tasks, the best agent in the paper scores 61.2 percent when you ask once.

Ask it the same task eight times and require every one to succeed, and it falls under 25 percent.

Your demo was one draw. Your Tuesday is eight hundred.

This is why the automation that impressed you on Friday is quietly producing nonsense by Wednesday. You did not get unlucky, and the model did not get worse. You sampled once and read it as a rate.

Agents do not know when to stop

Meta’s Gaia2 benchmark has a split where the environment keeps moving whether the agent acts or not, which describes every real business. A lead replies. A price changes. An order is cancelled.

GPT-5 scores 0.0 percent on that split, with zero variance across three runs. Grok-4 and Qwen3 also score zero.

Agents are built to complete. They are rarely built to notice that completing stopped being the right move.

Combine that with an opt-in error workflow and a 14-day log, and you have built something that will confidently do the wrong thing, report success, and erase the evidence.

Handoffs are where multi-step work dies

Carnegie Mellon built a simulated company with real project software, real chat, and 16 simulated colleagues, then set 175 ordinary knowledge-work tasks. The best submitted agent finished 42.86 percent.

If you are chaining agents, count your handoffs before you count your capabilities. Every handoff is a place for context to be dropped, and the handoff count predicts your week better than the model name does.

And almost nobody checks any of it

LangChain surveyed 1,340 practitioners. 89 percent had observability running. 52.4 percent ran offline evaluations. 29.5 percent ran no evaluations at all, including 22.8 percent of teams with agents already in production.

Nine in ten are watching. Three in ten are checking. Those are different activities and people confuse them constantly.

Observability tells you the workflow ran. Evaluation tells you it was right. The green dashboard is the first one wearing the clothes of the second.

The minimum useful version is twenty examples with the correct output written down, run every time you change a prompt. That is not sophisticated and it will still put you ahead of most of the market.

The One I Got Wrong

I should put my own in here, because this is easy to write and harder to live by.

I run an automated process that writes and posts on my behalf. It had a guard: before anything goes out, compare what was produced against what was intended, and stop if they differ. Good design. I was pleased with it.

The guard compared character counts.

Then the format changed slightly, and the underlying defect changed shape with it. Instead of producing a clean duplicate, which a length check catches easily, it started splicing text into the middle of what was already there. The count still looked plausible. Eight items went out mangled before anyone noticed, and they had to be deleted one at a time.

The check was real. It measured the wrong property, and it had never once been tested against the failure it existed to catch.

The fix was comparing the exact text instead of its length. It caught the next failure within minutes of being installed.

So when I say break your guard on purpose while you are watching, that is not a best practice I read somewhere. It is a bill I paid this month.

Why This Lands Differently in East Africa

The self-hosting case is stronger here than almost anywhere, and that makes the ownership bill larger rather than smaller.

The reasons to self-host are real

Dollar subscriptions against local revenue are a genuine problem, and so is having a card that works reliably for recurring international payments. A VPS you pay for monthly at a low fixed cost solves both.

Add data residency questions for anyone handling customer records under local regulation, plus the plain fact that engineering time here is cheaper relative to a Silicon Valley SaaS subscription than it is in London.

Self-hosting is often the correct answer. I am not arguing against it.

The consequence people skip

Every one of those reasons also means there is no vendor patching your box at 3am.

The founder who chose self-hosting to avoid a 50 dollar monthly bill has taken on a security duty with a real cost attached, and that cost is paid in attention on a schedule rather than in cash once a month.

Some of those 24,700 exposed instances belong to businesses that self-hosted for exactly the right reasons and then had nobody whose job it was to update them.

The compounding version

Where a business runs on mobile money, a WhatsApp thread with a supplier, and a spreadsheet, automation is genuinely transformative. It is often the first time the operation becomes legible enough to be valued, lent to, or handed over.

That is the prize and it is worth chasing hard.

It also means the automation is now carrying the only structured record the business has. Which raises the stakes on the boring questions considerably: who else can log in, what happens when it stops, and how would you know.

Measure the Before, Because You Will Not Remember It

One more thing sits underneath all three bills, and it is the reason a lot of automation gets built that should never have existed.

People are poor judges of their own throughput.

The study that should be better known

METR ran a randomized controlled trial with 16 experienced open source developers across 246 real tasks, in repositories they already knew well.

Before starting, the developers predicted the tooling would speed them up by 24 percent. Afterwards, they believed it had sped them up by 20 percent.

Measured, they were 19 percent slower.

Faster and feeling faster came apart, and not one person in the room could tell from the inside.

The easy reading of that is wrong, so be careful with it. It does not say the tools are useless. It says the people using them lost the ability to judge their own output, which is a stranger and more awkward finding.

The same shape at organization scale

DORA studied nearly 3,000 professionals across 104 countries and found that for every 25 percent increase in AI adoption, delivery stability fell by 7.2 percent. Their own explanation was that teams had skipped the basics, small batches and proper testing.

Adoption went up. The thing adoption was supposed to improve went down. Nobody involved was incompetent.

So write down the before

Before you automate a task, record two numbers. How long it takes today, counted rather than remembered, and how often it happens.

Then record what it costs when it goes wrong, because that is the number that decides how much guarding it deserves.

Your memory of the before is not evidence. It gets rewritten the moment the new thing exists.

Half the time this exercise kills the project, and that is the exercise working. A task that takes eleven minutes a week does not need a workflow that somebody has to own, patch and monitor for the next three years.

The automations worth building are the ones where you can state the hours saved and the cost of failure in the same sentence.

What Actually Works

Eight things, in the order I would do them.

One. Build an error workflow and attach it to everything

One afternoon. It is the highest-return hour in this entire piece.

Two. Add a content assertion to every workflow that matters

Zero rows, missing field, empty response: fail loudly on purpose. Status checks pass while the work is wrong.

Three. Break each guard once, on purpose, while watching

Confirm the alert arrives somewhere a human reads. Untested alerting is decoration.

Four. Extend your execution retention before you need it

The default is a fortnight. Disk is cheap and the day you want the history is the day you cannot create it.

Five. Put patching on the calendar

A recurring slot, decided now. Subscribe to the advisories. Assume something rated 9.9 will arrive again, because in nine months it arrived four times.

Six. Audit who can create a workflow

That permission is equivalent to holding every credential in the business. Offboard within the week.

Seven. Treat community nodes as code with full credential access

Publisher, download history, maintenance. Prefer the built-in node even when it is uglier.

Eight. Write twenty test cases for anything with an agent in it

Expected input, expected output. Run them whenever you change a prompt. It is an afternoon and it puts you past 29.5 percent of the market.

The Thing Worth Taking Away

The automation platform question has been settled in the founder’s favor. Building is cheap, the tools are excellent, the licensing is generous, and SAP just paid 5.2 billion dollars to agree with you.

None of that touches the part that actually determines whether your automation is an asset or a liability.

An automation with no owner is not an asset. It is an unexploded liability with a green dashboard.

So the question to ask about every workflow you are running is not whether it works. Ask who would know if it stopped, how long it would take them to find out, and what it would cost while nobody knew.

If you cannot answer those three, you do not have an automation. You have a habit that happens to be running on a server.

I am Joshua Pi’Rwot. Country Director at AVODA Group in Uganda and founder of FounderWise. Nine years in East African accelerators, 613 entrepreneurs trained, 68 startups supported, and a lead pipeline that runs on the platform I just spent this entire post warning you about.

Sources are all public: n8n’s docs and security advisories, Pillar Security, Endor Labs via The Hacker News, CISA’s KEV catalog, Sierra’s tau-bench, Meta’s Gaia2, CMU’s TheAgentCompany, and LangChain’s State of Agent Engineering. Ask and I will send the links.

If you run automations in your business, tell me the last time one of them failed and how you found out. That answer tells you which of these three bills is already overdue.