I Diagnosed a Silent n8n Failure That Had Been Broken for Weeks

The workflow had been broken for three weeks. I only found out because my content queue looked empty.

It was a 17-node n8n workflow that polled Postiz every 15 minutes for scheduled social media posts. It checked each post's due time. If the time matched, it called Postiz's publish API. Then it logged the result. The workflow ran every 15 minutes around the clock. Every execution showed a green checkmark.

Nothing was publishing.

I checked the execution logs. Each run completed successfully. No errors. No warnings. The final node, the one that logged the result, showed a clean output. But when I looked closer, the output was an empty array. Every single time.

The API call to Postiz was failing silently. And n8n was treating the failure as success.

The Root Cause: Two Docker Networks

The failure was not in n8n. It was in Docker.

I had n8n and Postiz running on the same Mac Mini, both in Docker containers. But when I looked at the network configuration, I found the problem. n8n was on the default bridge network. Postiz was on a named network I had created months earlier for a different project.

Docker containers can only resolve hostnames for other containers on the same network. n8n was trying to reach http://postiz:5000. The hostname postiz did not exist on n8n's network. So the request failed with ENOTFOUND.

But n8n's HTTP Request node did not throw an error. It returned an empty response body with a 200 status code. The workflow's logic checked for a non-empty response to determine success. An empty response passed that check. The workflow logged a success. The green checkmark appeared. And nothing published.

This had been happening every 15 minutes for 21 days. 2,016 silent failures. All marked as successful.

Why It Took Three Weeks to Notice

The workflow was a background task. I set it up, activated it, and moved on. The content queue was supposed to drain automatically. I checked it manually once a week, but the queue had been empty for so long that I assumed I just had not scheduled anything.

The real signal was when I ran my content calendar check and saw no scheduled posts. I checked Postiz directly. 14 posts were queued, all past their due times. Then I checked n8n. Every execution was green. The disconnect between "all green" and "nothing published" took an hour to trace.

This is the danger of silent failures in automation. A workflow that errors loudly is easy to fix. A workflow that fails quietly becomes invisible infrastructure. You stop thinking about it because it never asks you to.

I have written about keeping your automation pipeline healthy and about building an evaluation gate that catches failures. The pattern in each is the same: the failure is only a problem when nobody can see it.

The Fix: Not a Config Change

The first fix was simple. I put both containers on the same Docker network. n8n could now resolve Postiz's hostname. The workflow started publishing again.

But that was not the real fix. The real fix was recognizing that a 17-node n8n workflow polling an external API every 15 minutes was the wrong tool for the job. n8n is an orchestration platform. It is not a cron scheduler. Running a polling loop inside a workflow engine adds failure surface area for a task that needs none.

I rebuilt the workflow as an 80-line Python script. It runs from a cron job on the Mac Mini. It queries Postiz's API directly. It publishes due posts. It logs to a local file. If the API call fails, the script throws an exception and the cron job emails me.

The script has no workflow engine. No nodes. No visual editor. No Docker network dependency. It is a single file that does one thing. If it breaks, I get an email. If it works, I forget about it.

This is the same move I made when I replaced a polling setup with Cloudflare Tunnels and when I consolidated my automation stack. The pattern holds: fewer moving parts means fewer places for a failure to hide.

The Lesson: Make Failures Loud

The n8n workflow failed silently because the failure path looked like success. The HTTP Request node returned an empty body. The next node checked for a non-empty body. An empty body passed the check. The workflow completed. The green checkmark appeared.

I now write all automation logic with explicit failure handling. If an API call returns an empty response that should not be empty, the workflow fails. If a cron job produces no output, it emails me. If a scheduled task runs and changes nothing, I want to know.

The goal is not to prevent failures. The goal is to make failures impossible to ignore.

If you run n8n at all, this applies to you. I run n8n as my marketing automation engine for clients, and I have seen the same silent pattern in their setups: a node configured to continue on error, an empty response treated as success, a workflow that looks healthy while doing nothing.

Why This Matters

This is not a story about n8n being bad software. n8n is excellent at what it does. This is a story about using the right tool for the right layer of the stack.

Workflow engines are for orchestrating multi-step processes across multiple systems. Cron scripts are for scheduled tasks that touch one API. When I blurred that boundary, I created a 17-node solution to an 80-line problem. The complexity hid the failure.

The same pattern shows up in other stacks. Teams build 40-node Zapier workflows to send a weekly email. They deploy Kubernetes clusters to run a single cron job. They add message queues to processes that process one message per hour. Complexity is not a virtue. It is a liability that compounds.

I believe the best automation is the one you can explain in one sentence. If you need a diagram to explain why something is broken, the system is too complex.

When I built my local coding agent loop, I hit the same wall: a harness that judged and described with one model was too complex to trust. Splitting perception from judgment made the failure modes visible. Simpler architecture, louder failures.

The Checklist

If you run scheduled workflows in n8n or any other engine, ask these questions:

1. Does the workflow touch one API or many? If one, consider a script.
2. Does the schedule interval match the tool's design? Polling every 15 minutes inside a workflow engine is a smell.
3. What does success look like? An empty response is not success if you expected data.
4. Who notices when it breaks? If the answer is "me, eventually," add an alert.
5. Can you explain the failure path in one sentence? If not, simplify.

The 17-node workflow is gone. The 80-line script is running. I have not thought about it since.

If you are running self-hosted automation and want a second pair of eyes on the failure modes, get in touch. I find these silent failures for a living.