One-off workflows are liabilities
The default n8n adoption path: build one webhook automation that fixes a Monday-morning pain. Build another for a quarterly report. Add a third for review capture. After six months there are 14 workflows, three are silently broken, and nobody remembers what credentials feed which.
The collapse happens when a workflow that feeds revenue silently fails for 36 hours. The team finds out from a customer. The fix is not "better workflows" — it is moving from a folder of automations to an infrastructure.
The five properties of stack-grade automation
- Idempotency on every external write. Retries cannot create duplicates.
- Error dispatch — every workflow has a global error trigger that posts to Slack and writes to a dead-letter queue.
- Documented contract per surface: webhook URL, expected payload, idempotency key, side effects.
- Observability — Inngest, n8n executions, or a custom dashboard showing run counts and failures by workflow.
- Versioning. Workflow JSON in git; production deploys reviewed.
Failure modes that take down the pipeline
The three failure modes that kill automation stacks: credential expiry without alerting, partial failure (one external call succeeded, the next failed, no rollback), and silent schema drift (the upstream API changed a field and the workflow continues without throwing).
All three are addressable, but only if the stack is designed to surface them. Watching the n8n execution dashboard is not surfacing. Slack alert + dead-letter queue + weekly autoloop review is surfacing.
A reference architecture
For a typical 8-12 workflow stack: self-hosted n8n on Railway (under your billing), Slack workspace for alerts, Supabase for the dead-letter queue and any state that needs persistence, a GitHub repo for workflow JSON exports, and one runbook page per workflow. Total operating cost: ~$200/mo of infrastructure. Total uptime over six months: 99.9%+.