# Nothing was on fire. Nothing was working.

2026-10-13 . Mike Boscia . https://e5bravo.com/hnt/nothing-was-working/

It is 10:42 on a Friday night, February 20, and I need keyword data for a store.

The pipeline is supposed to have it. A scheduled workflow pulls ranked keywords and drops them in the database, so all I should have to do is look. I look. Nothing there. Fine, I will pull it by hand. Attempt one times out. Attempt two times out. Attempt three times out.

Eleven minutes later I am asking a different question entirely: why has the keyword workflow been failing since February 4?

Since February 4. Sixteen days. Seventeen by the UTC clock on my own messages, and I am not going to argue about the one day.

No alert fired, because there was no alert. Nothing paged me, because there was no pager, no on-call, no incident channel. The workflow stopped doing the one thing it existed to do, and everything stayed quiet. I found out because I needed the data, and it was not there.

New Achievement!

**Absentee Landlord**

Your workflow has failed for sixteen days. Nobody noticed.

Reward: none.

## The smoke detector with no battery

A smoke detector with the battery pulled is silent in exactly the same way as a smoke detector in a house that is not on fire. From the hallway you cannot tell them apart. The only way to know is to press the button.

For sixteen days I did not press the button. I would like to report that some instinct nagged at me around day nine. Nothing nagged. I believed a job was getting done that was not getting done, and I believed it for the most reasonable reason there is: nothing said otherwise.

Here is the part that should sting. I have sold observability. I have stood in front of buyers and explained, straight-faced, that the failure that gets you is never the one that pages you. It is the one that does not. No news is not good news. It is not bad news either. It is worse than both: the absence of information, plus the natural, naive assumption that everything is hunky dory because nobody came running in with their hair on fire. I sold that pitch for a living. Then I ran a workflow on a schedule and waited for someone to come running. Nobody did.

It gets better. On January 26, in my own lessons file, under a heading that reads "Signals That Current Approach is Fundamentally Broken," I wrote this:

> Don't polish a broken tool. Switch tools.

Then I kept polishing it for another month. I had written the warning label for the smoke detector myself, and never put in the battery.

## Then I checked the rest of the house

You could read sixteen days as a fluke. One sloppy operator, one dead battery. That was my first theory too, and I was fond of it, because it only required me to have failed once.

An n8n workflow collecting merchant product data. Every node returned HTTP 200. Task IDs came back valid. The database stayed empty. An Aggregate node had collapsed 5 items into 1, the next node returned null instead of an array, and 360 products were fetched successfully and then had nowhere to go. Every light green. Zero rows. That is not a dead battery. That is a detector with the green light on and no sensor inside.

And the worse one. A Code node paired the outputs of two nodes by array position: item 0 from one list with item 0 from the other, on the assumption that they were the same record. They were not always. The database could hand rows back in its own order, and when an insert failed, every index after it shifted. 13% of records came out missing their detail data. That is the number we could count. The worse number is the one we could not, because a shifted index does not only leave holes. It attaches data to somebody else's record, where it sits looking exactly like correct data. Missing data leaves a hole you can find. Wrong data fills the hole. That is a detector wired to the neighbor's house.

If you run n8n, Zapier, or Make, you pair two lists somewhere eventually, and pairing by position is a built-in option, not an exotic mistake. n8n's Merge node has a mode for it, Combine by Position, and by default it quietly drops whatever does not pair up. You may have this bug right now with no way to know. I had it and felt great.

We keep records on this. Bug files, decision records, lessons files, postmortems: roughly 540 of them across our own systems. Nobody plans an archive like that. It just accrues. Of the failures fit to publish, about two thirds have the same shape. The system kept running, kept reporting success, and produced wrong or missing output until a human went looking.

So here is the thesis of this series, and honestly of the business. Automation does not fail loudly. It fails quietly, keeps reporting success, and you find out when you need the thing it was supposed to have done.

## No-code is not the villain

Now the concession, because a case this one-sided should make you suspicious. n8n carried our data collection from September to February. If you have a job that runs twenty minutes a week off a spreadsheet, no-code is the right answer. I mean it. The failure modes above cost more to prevent than that job is worth, and anyone telling you to rewrite it in Python is selling you something. I am aware of who that description fits.

The problem is not the tool. The problem is the twenty-minute job that quietly becomes the thing your pipeline depends on, while its monitoring stays at twenty-minute-job level: which is to say, none.

## Press the button

Pick the one scheduled job your business would miss first. Now answer two questions without opening its status page.

1. When did it last write a row?
2. If it stopped tonight, how would you find out?

If your answer to the second one is "it would tell me," it will not. Mine did not, for sixteen days. Open the table, not the dashboard, and count what its last scheduled run actually wrote. If you cannot answer the first question without the dashboard, you have found your dead battery.

That is what How Not To is. Our own systems, failing, with the date, the mechanism, and the check you can run on yours. No vendor will write this series, because no vendor publishes the failure modes of the thing it sells. We do not sell a platform. We have a filing cabinet full of our own failures and very little dignity left to defend.

Next post: the AI that told me two reviewers had signed off, and then, when I asked, told me the truth. Before you read it, go press the button on yours.

*P.S. This is one of the reasons I stopped building workflows in n8n, where every workflow is a JSON file, and switched to Prefect running plain Python. The way we were using n8n, as the backbone of a data pipeline, it was buggy, unstable, inconsistent, and enraging. That is its own post.*