Running automation in production
Content and business automation fails quietly rather than loudly. These are the failures that produce no error at all.
- Domain
- Automation
- Notes
- 7 items
- Source
- Shipped work
- Reply
- Within a day
What I already knew before the kickoff call.
A self-hosted 30+ node pipeline in production, 600+ delivered assets across 14 client accounts, and ten live transactional email flows.
Test runs are not free, and the tool will not tell you
Pinned sample data is honoured by the editor's run button and ignored by the command-line runner, which re-executes every node for real. Three test runs believed to be free had each made real paid model calls. Check how your runner treats pinned data before you iterate.
A secret that works in a test run may not exist in the scheduled run
Passing an environment variable to a one-off test process never puts it in the long-running container. The workflow passes every manual test and then throws on the first real cron or webhook trigger, on the one node that reads the secret. Put it in the persistent environment and recreate the container, because a plain restart reuses the old one.
A merge step can silently collapse your branches
Combining N inputs by position produces one item, not N, and identical keys across branches overwrite each other with no error. It reads as working right up until someone counts the output. Append and combine are different operations and the wrong one is invisible.
Measure the model cost before you scale the run
An estimate of 32 vision calls per item measured out at 13.3, which changed the plan for a 300-item run to roughly 4,000 calls and five hours. That is a number worth having before the run, not after the invoice.
The most frequent item is rarely the easiest one
Ordering a backlog by frequency sounds efficient and picked the hardest cases first: the generic entries with the worst source coverage. Hit rate collapsed. Order by expected success, then check the frequency.
Deliverability is the provider's problem until you prove it is not
A stalled campaign is more often a provider-side queue than a bug in your integration. Trace the message state at the provider before rewriting your own sending code: on one engagement that traced 9,800 stuck emails to the provider rather than to the platform.
Where this happened: Fixing Live SystemsReplacing default transactional email is a mapping exercise
Ten flows replaced every default notification, each one mapped to real order and customer data rather than to a template's placeholder fields. The work is in the data mapping and the trigger conditions, not in the design of the email.
Where this happened: Made-to-Measure Shopify Platform
The same notes, other ground.
Working in one of these?
Tell me what is happening in your own words. I will tell you within a day whether it is mine to solve, and roughly what it takes.