Most automation mistakes aren't silent — the canvas is already telling you, in small signals that are easy to skim past if you're focused on just getting a workflow to run at all. Here's what to actually watch for, beyond the obvious red border.
A green border isn't the same as a correct result
A node turns green when it runs without throwing an error — that's a lower bar than "returned the right data." An HTTP Request node that successfully calls the wrong URL, or a Custom Agent node that successfully returns an empty string for a field your prompt should have populated, both show green. Green means "didn't crash," not "definitely correct" — the actual check is reading the test output, not just the color.
A blank or unchanged value in test output
This is the quietest and most common real mistake: a binding pointing at a field that doesn't exist in the upstream data doesn't throw an error — it just resolves to nothing, and a template placeholder with no bound value often just shows as blank or as its own literal {name} text. Nothing turns red; the post is simply wrong. Reading the Apply Template node's test output carefully, not just glancing at whether it ran, is what catches this.
A Custom Agent's output that's technically valid but generic
A schema can validate successfully against output that's still low-quality — a headline field that's present but bland, a sentiment that's technically one of the allowed values but not actually a considered judgment. The node won't flag this; only actually reading the drafted text does. This is exactly the gap prompt specificity closes — a vague prompt produces valid-but-weak output the schema will happily accept.
An If node that's always true, or always false
If a relevance or threshold filter never blocks anything across several test runs, either the condition is too loose to be doing real work, or your test data happens to always clear it — worth deliberately testing against an item that should fail the condition, to confirm the filter actually filters (see If node recipes).
A workflow that's only ever seen its own test data
The mistake that doesn't show up in the canvas at all: a workflow tested only against one clean, hand-picked example can look completely correct and still fail the first time a real response is missing a field, or shaped slightly differently than expected. This is why the pre-launch checklist insists on varied test inputs, not just a single passing run — the canvas can only warn you about what it's actually seen.
The habit this all points to
None of these mistakes require special tools to catch — they require actually reading the test output rather than treating "it ran" as the finish line. A node turning green is the start of a check, not the end of one; the canvas gives you everything you need to catch these before a real run publishes, as long as you look past the color and into the actual content.