Why I moved recurring automations from n8n to Inngest
This is not a “n8n is dead” post. Visual, branchy automations still live there — Slack-to-site publishing and the feedback agent among them. What moved is the recurring and event-driven layer.
Full production arc: AI automation in production.
What broke with cron-on-a-laptop
Scheduled digests, monitors, and site webhooks need to survive a failed external call mid-run. A single long n8n execution that dies halfway loses the whole job. Babysitting cron on a machine that sleeps is not an operating model.
What Inngest changed
On tur-automations (Next.js on Vercel), each workflow is a durable function with steps that retry independently. Triggers are cron schedules or events. When an LLM call or deploy hook fails, the platform resumes from the failed step.
In production today, in priority order:
- Daily AI vendor digest
- Daily signal monitor
- Human-in-the-loop approvals via Telegram before high-impact actions
- Daily synthetic site checks
- Event-driven site flows (newsletter signup, contact notification)
Split of responsibilities
| Layer | Tool | Why |
|---|---|---|
| Branchy, visual, human-edited paths | n8n | Fast to reshape; good for publishing and conversational agents |
| Durable schedule + webhook work | Inngest | Step retries, observability, no laptop cron |
| Multi-agent with roles and spend | The Unnamed Roads | Approvals, tracing, cost routing — see guardrails |
The shape stayed the same: deterministic checks around generative steps, humans on the irreversible ones. Only the orchestration substrate for recurring work changed.