Imagine: a customer pays for your course. Money hits the account. Webhook fires. N8n starts its magic — record the payment in the database, send an email, update the dashboard.
But somewhere in the middle, something goes wrong. Maybe the database was unavailable — we were updating it. Maybe we didn't pick the right time for deployment. Doesn't matter. What matters: the process was interrupted without a trace.
Result? The money is there (WayForPay confirmed the payment). But in our system — nothing. No record, no email, nothing in the customer's personal dashboard.
Good thing the customer wrote to support. We dug through the logs, found the successful payment with the provider, added it manually. But how many such "silent" failures did we miss? How many customers just left a negative review somewhere online, and we never even knew why?
That's when I realized: the problem wasn't n8n. The problem was the approach. I didn't need a "task executor", but a processor that remembers state and can retry only what failed. Not the entire flow again. Just what didn't finish.
It wasn't the technology that failed. It was the architecture of thinking that was wrong.
How n8n Works (And Where It Breaks)
N8n executes nodes sequentially — one after another. It doesn't matter how they look graphically on the canvas. Only one thing matters: execution order. Signal arrives, node 1 executes, node 2 executes, node 3...
Sounds logical. But here's the problem: if node 2 fails with an error, nodes 3, 4, 5, 6 simply won't execute. The process stops. And that's it.
Technically, yes, you can add an error handler (Error Trigger) for each node. But imagine: you have a flow with 10 steps. You need to add 10 error handlers? That's not automation — that's jungle.
The Problem Isn't Errors. The Problem Is Forgetting.
N8n beautifully connects services together — that's its strength. Slack, Google Sheets, CRM, email — everything works "out of the box". But here's the nuance: n8n doesn't know that the process was interrupted somewhere. It doesn't preserve context. It doesn't remember that nodes 1 and 2 already executed successfully, but node 3 didn't.
For it, each execution is a separate event. A webhook came in, it did what it could, closed the task. Next time it starts from scratch, as if there was no previous attempt.
What Does This Mean in Practice?
In our case with the payment, the signal arrived successfully. Attempt to write to the database — error. Email wasn't sent. Dashboard wasn't updated.
N8n doesn't know that it needs to retry these specific steps. It just finished execution with an error and moved on. Process lost. And if the customer hadn't written — we would never have known.
Event-Driven vs Process-Driven Architecture
N8n thinks in events. Trigger fired, reacted, forgot. Successfully or not — doesn't matter. Context lost.
The main problem isn't the technology. The problem is that a payment is not an event. It's a process.
The Difference Between an Event and a Process
An event is a trigger. Something happened, a reaction is needed, done. Like a task to a subordinate: "Do this now", done, next task.
A process is different. It's a sequence of steps with state. Payment made? Recorded in database? Email sent? Access granted? Each step depends on the previous one, but they can even be executed in parallel.
Why Is This Critical?
In real business, there are very rarely "one-off" actions. Even what seems simple — delivery, payment, registration — are actually processes with multiple states.
Let's return to our example. A payment consists of steps: webhook came from WayForPay, write transaction to database, send email confirmation, grant access to course. Technically, the last two steps can be executed in parallel. Or even grant access first, then send email — that sounds more logical.
But what if the database write fails?
Then it doesn't matter what order the other steps executed in. We don't have a transaction record. And that means we don't know that the customer paid.
We can't show them payment history. In any dispute, we have no proof. And if the email or access also didn't work — the customer is completely in the dark.
N8n Doesn't See the Process. It Sees Events.
For n8n, each webhook is a separate event. It doesn't know that step 1 executed successfully, that step 2 failed, that steps 3 and 4 never started. It just closed the execution and went to wait for the next webhook.
Business Thinks in Processes, Not Events
When you think about a payment, you don't think "webhook arrived". You think: "Customer paid, we recorded it, they got access, all good". It's a chain. It's state that changes. It's a process.
And if something fails in the middle — the process should continue from where it stopped. Not start over. Not forget what's already been done. This is what n8n can't do. It doesn't preserve state between steps.
What if a process could preserve its state? That's exactly what Temporal does.
Temporal: When the Process Remembers Itself
Imagine that each step of your process is recorded in a journal. Not just "executed" or "error". But specifically: what happened, when, and what needs to be done next. That's Temporal.
How Does It Work?
Temporal stores process state in an event log. Essentially, these are the same steps as nodes in n8n. But with one critical difference: they have shared context.
Each step writes to the journal: "Webhook arrived at 14:32", "Attempt to write to database — error, database unavailable", "Email not sent (database unavailable, no transaction ID)". And Temporal doesn't forget about this.
What Happens on Error?
Database down? Service unavailable? No problem.
Temporal doesn't close the process. It saves the journal and waits. A minute later, an hour later — when the database is available again, Temporal opens the journal and says: "Aha, I need to complete this step. Database working again? Okay, continuing."
And it executes only what didn't finish. Not the entire process again. Only the step that failed.
The Same Payment, But in Temporal
Let's return to our payment. Here's how it would look in Temporal.
Webhook arrived — recorded in journal: "Process started. Payment ID: 12345. Customer: ivan@example.com. Amount: 500 UAH."
Attempt to write to database — error: "Database unavailable. Retry in 1 minute."
Retry attempt in a minute — success: "Transaction recorded. Database ID: 987. Moving to next step."
Send email — "Email sent to ivan@example.com. Confirmed."
Grant course access — "Access granted. Process completed."
Result: Customer got everything they should have. You see the complete history in the journal. No "silent" failures.
The Process Doesn't Get Lost. It "Sleeps" and "Wakes Up"
The key difference: Temporal doesn't close the process on error. It suspends it.
N8n on error says: "Well, didn't work out. Bye." Temporal says: "Didn't work out now. Will try later." And it really will try. Automatically. From the exact place where it stopped. Without your intervention.
This Isn't About Complexity. It's About Reliability.
Yes, Temporal is more complex to set up than n8n. There's no drag-and-drop visual editor. You need to write code. But the cost of error is different.
In n8n, an error means a lost process. You'll find out only if the customer writes. In Temporal, an error means a suspended process. The system knows it needs to continue.
For simple integrations, there's no difference. But when it comes to money, customer data, critical operations — process thinking is mandatory. Not every automation needs Temporal. But every critical operation does.
When to Use What?
The question isn't what's better. The question is, can your system survive a "silent" failure.
When to Use n8n
N8n is suitable for service integrations. Google Calendar with Calendly, process and move a new file on Google Drive, Slack notifications for CRM events, data synchronization between systems. It's also good for regular tasks where you can "catch up". Daily file import — if today failed, tomorrow I'll process two files. Data backup — missed one day, not critical. Mailings that can be repeated.
Simple criterion: if the process fails and you can "catch up" next time — n8n will work.
When Temporal Is Needed
Temporal is needed for financial operations. Payments, payouts, transactions — anything involving money. It's also necessary for business processes that cannot be lost. Customer registration with account creation and product access. Orders with processing and delivery. Subscriptions with charges and access renewal.
Different criterion here: if losing the process means losing money, a customer, or reputation — you need Temporal.
Simple Rule
Ask yourself: "What happens if this process fails in the middle, and I don't find out?"
If the answer is "nothing terrible, I'll catch up later", use n8n. If the answer is "the customer will lose money, access, or trust", you need Temporal.
Not every automation needs to be bulletproof. But every critical operation does.
Conclusion
Tools aren't to blame. They just do what they're designed for.
N8n is great for quick integrations and prototyping. Temporal is for processes we can't afford to lose. The question isn't what's better. The question is what we're using them for.
I understood this after that "lost" payment. The problem wasn't n8n. The problem was that I was using an event tool where a process tool was needed.
Now I ask myself a simple question: "Can this system survive a failure without losing context?"
If yes — n8n. If no — Temporal.
It's not technology that determines reliability. Understanding the nature of the process — that's what determines it.
"Stability isn't the absence of failures, but the ability to survive them without losing memory."
