The automation ran green and was wrong four ways

An automation that stops is the easy case. Someone notices, someone complains, and it gets fixed that day. The expensive one finishes. Every step completes, the log fills with green, and the number it hands you is wrong. Nobody notices, because there is nothing to notice.

On 5 August we built a daily sales report on n8n, to find out whether the tool was worth selling to clients here. A Google Sheet of rows in, a summary on a phone at 6pm out. Five working nodes, about two and a half hours including two failed installs and a Node version conflict. The workflow itself took under an hour.

It ran first time. It was also wrong in four separate ways, and three of those four came from the tool's own defaults and from a public template rather than from anything we wrote. That is the useful part. Knowing which screens to open is most of the work, and it is not the part anyone sells you.

Nobody commissioned this build and no client data went near it. The sheet holds sample rows and says so in its own title.

The label is not the setting

n8n ships with its timezone set to America/New_York. We rechecked that on 9 August 2026 and it was still the default.

Our trigger said "every day at 6pm". In Nairobi that fires at 2am. The report's idea of "today" moves with it, so the message that did arrive would have summarised the wrong day's rows.

Nothing warns you about any of this. The trigger card still reads 6pm, which is the setting you chose, on a clock you did not. The timezone lives in the workflow's own settings, one screen away from where you were looking, and correcting it is a single dropdown once you know it is there.

Correct all afternoon, wrong after midnight

The template worked out today's date from UTC.

Nairobi runs three hours ahead, so a UTC date and a Nairobi date agree for most of the day and separate between midnight and 3am. Test it at four in the afternoon and it is perfect. Keep testing it at four in the afternoon, which is what actually happens, and it stays perfect right up to the point where it is quietly wrong on a fraction of days, permanently.

That shape is worth learning to recognise, because it survives testing by design. Anything that depends on "today", "this week" or "since yesterday" needs checking at the edge of the day rather than the middle of it. If you cannot sit down at 1am to watch it run, feed it a 1am timestamp and read what comes back.

A name in the dropdown is not a connection

The template carried a Google Sheets credential with an empty id behind it.

n8n renders a credential's name whether or not anything is attached to it, so the dropdown read "Google Sheets account" and looked wired up. In the workflow's JSON, the id sitting next to that name was an empty string.

Open every credential on an imported workflow and re-select it by hand, including the ones that look right. On a workflow you did not build, a name in a box is decoration until you have put it there yourself.

Read the error literally

The Telegram step failed with "the bot can't send messages to the bot".

We lost time assuming it meant something cleverer than it said. It did not. A chat id had been read from the wrong part of the API response and belonged to the bot itself, so the report was being addressed to the thing sending it.

Automation errors are usually accurate and rarely obvious. They describe what happened in the vocabulary of the system rather than the vocabulary of your problem, and the distance between those two is where the afternoon goes. Read the message once more before you start theorising.

Free templates are still worth using

The n8n community library holds over 11,000 free workflow templates. The one we started from, number 13486, reads sales rows and sends a formatted summary. Downloading it took a minute.

It was also written for someone else's business in someone else's country. It delivered through a paid WhatsApp bridge priced in dollars, and it ran on New York time. None of that makes it a bad template. It makes it somebody else's template, which is a different problem and a solvable one.

Budget the afternoon it takes to make it yours. That afternoon is the difference between a workflow that runs and a workflow you can trust with a number.

What we open before trusting one

Four screens, in this order:

• The workflow's settings, for the timezone. Not the trigger card, which will happily agree with you.
• Any step that works out a date, run against a timestamp from the wrong side of midnight.
• Every credential on an imported workflow, re-selected by hand rather than read.
• The raw JSON, at least once, for the fields the interface renders too politely to doubt.

Then the first real error message, read literally, before any theory about what it "really" means.

None of this needs you to be a developer. It needs somebody to look before anything real depends on the output, and to know that a green log is a statement about whether the steps finished, not about whether the answer is right. When we build automation for a client, that checking is most of what the price covers. The wiring is the easy half.