7. The shared responsibility map

Overview

By the end of this lesson you'll know how to draw a line almost nobody draws until they need it in the middle of a crisis: where your responsibility ends and the provider's or the external system's begins. You'll understand what n8n guarantees —different in Cloud than in self-hosted— and what stays on your side; you'll distinguish responsibility for the cause of a failure from responsibility for the response, which is the distinction that saves the operation; and you'll know how to document that boundary before you need it, verifying what the providers say officially without making up guarantees no one signed.

This matters because the moment you discover where the line was shouldn't be the moment something broke. In a crisis, the question "whose is this?" becomes urgent and poisonous: the team freezes pointing fingers, the provider says "it's your configuration," you say "it's their service," and meanwhile the customer still doesn't have their order. A responsibility map drawn calmly, beforehand, turns that question from an argument into a lookup: you look at the map and you know who moves what. And there's an uncomfortable truth this lesson faces head-on: the line of whose fault it is and the line of who the customer calls almost never coincide, and operating well is taking charge of that difference instead of fighting it.

Connection with the module: this lesson closes the module's cycle of judgment. Lesson 2 taught you to recognize that a workflow is production; lesson 3 to classify it; lesson 4 to know what it's missing; lesson 5 to change it; lesson 6 to organize it. This one answers the last question before the project: when this fails —and it will fail— what part is yours and what part isn't, and what do you do with the part that isn't yours but falls on you anyway? It's the lesson that connects module 1 with module 8, because a runbook and an on-call rotation are built on knowing who answers for what. And it touches the boundary with the sibling guides: what here is "the infrastructure provider's responsibility" is operated in depth in the self-hosting guide; here we only draw the line.

The restaurant and the tomato supplier

Let's start with the image that orders the lesson, because the abstract model is understood instantly with it.

A restaurant buys tomatoes from a supplier. One morning, the supplier delivers a box of rotten tomatoes. Now follow the chain of what happens:

The cook, in a hurry, doesn't check the box well and uses the tomatoes in the day's sauce. A diner orders the dish, tastes it, and it tastes horrible. The diner calls the waiter, upset. Who do they complain to? Not the tomato supplier —they don't even know it exists. They complain to the restaurant, because the restaurant is who served them the dish. To the diner, the supplier chain is invisible: they see a single responsible party, the one who put the dish on their table.

Now the question that orders everything: whose fault was it? The supplier's, who delivered bad tomatoes —that's the cause. But whose responsibility is it that the diner eats well? The restaurant's, which should have checked the tomatoes before using them —that's the response. Both things are true at once, and they don't contradict each other: the supplier caused the problem, and the restaurant was responsible for responding to it. A good restaurant doesn't defend itself by saying "it's not my fault, it was the supplier." A good restaurant checks the tomatoes, because it knows the diner will complain to it no matter what, and that's a reality you don't change by fighting it, only by accepting it.

Your operation is that restaurant. n8n is your kitchen. The erp, the carrier, the storefront are your tomato suppliers. And Terra Market's customer is the diner: when something goes wrong, they call you, not the provider whose API went down. From there comes the thesis of the lesson, and it's the most important one you take from the module about dealing with the external:

Responsibility for the cause is shared; responsibility for the response is yours. That an external system fails isn't your fault. That your operation responds badly to that failure, that is. The customer doesn't distinguish the two, and your job isn't to make the fault someone else's: it's to check the tomatoes.

The three layers of responsibility

To draw the line precisely you have to see that there aren't two parties, there are three layers, and the line falls in a different place depending on where you run n8n.

Layer 1 — The infrastructure. The server where n8n lives, the database that stores your workflows and executions, the network, the operating system, the backups, the updates of n8n itself. It's the "kitchen" as a physical premises: the walls, the gas, the refrigerator.

Layer 2 — The application and its contents. Your workflows, their logic, their credentials, the correctness of what they do. It's what you cook: the recipes, the hygiene, checking the ingredients. This layer is always yours, wherever you run. Nobody else can write your workflows well or decide what permissions your erp credential carries.

Layer 3 — The external systems. The erp, the carrier, the storefront, the AI provider. They're the tomato suppliers: you don't control them, they have their own failures, and their behavior is a fact of reality you work with, not something you operate.

The question of the shared responsibility model is: where does the line between what's yours and what's the provider's fall in layer 1? And the answer depends entirely on how you run n8n.

On n8n Cloud

If you use n8n Cloud, layer 1 is n8n's. They handle the server, the database, the updates, the infrastructure. You dedicate yourself to layer 2 —your workflows— and coexist with layer 3 —your external systems.

Here I have to be very careful with what I assert, because it's easy to make up guarantees, and a made-up guarantee is worse than none. This is what I could verify against n8n's official documentation at the time of writing this guide, and that it's worth you confirming at the current source, because these things change:

• n8n makes backups of its customers' data regularly, replicated to another region and encrypted. Layer 1 includes that backup; you don't have to set it up.
• n8n keeps your workflows and credentials until you delete them, and keeps execution data according to your plan's retention policy —which is different in each plan and worth looking at, because it defines how far you can "look back," as we saw in lesson 2.
• n8n publishes a status page where it reports whether its platform has an incident. It's the first place to look when you're unsure whether the problem is yours or theirs.

And this is what I won't assert, because I mustn't make it up: I'm not going to give you an availability number ("99.9% uptime") or a contractual SLA clause for n8n Cloud. Those numbers, if they exist for your plan, are in the contract and on n8n's official page, and they change between plans and over time. If you need that fact —for example, to promise something to your own business— go to the current official source and read it there. A serious operator doesn't cite a contractual guarantee from memory; they verify it in the document. Teach yourself that reflex right now: where there's a contractual figure, you verify it, you don't remember it.

What you can do with certainty is reason about the boundary: in Cloud, if the problem is that n8n's server is down, it's theirs —and you confirm it on their status page; if the problem is that your workflow has a misplaced if or your credential expired, it's yours, and no plan covers that.

In self-hosted

If you run n8n on your own infrastructure, layer 1 is also yours. The server, the database, the n8n updates, the backups, the network security: all of that moves from "the provider's responsibility" to "your responsibility." You gained control and you gained work in equal measure.

This is exactly what the n8n Self-Hosting and Operations guide covers, and that's why this guide doesn't develop it: setting up the server, choosing and backing up the database, applying updates without losing data, hardening the network. Here we only draw the line so you know it exists: in self-hosted, when the server runs out of memory at three in the morning, there's no provider to call. It's you. The advantage is total control; the cost is that layer 1 gets added to your list.

The table that sums up the layer 1 boundary:

Layer 1 (infrastructure)	n8n Cloud	Self-hosted
Server and operating system	n8n	You
n8n's database	n8n	You
n8n updates	n8n	You
Instance backups	n8n	You
Network security	n8n	You
Layer 2 (your workflows and credentials)	You	You
Layer 3 (external systems)	shared with the external provider	shared with the external provider

Read the table and notice the two bottom rows, highlighted: layer 2 is yours in both columns, and layer 3 is third parties' in both columns. The only thing that moves between Cloud and self-hosted is layer 1. This has a very concrete practical consequence: most of the work of this guide —error handling, observability, credentials, AI cost— is in layer 2, which is yours regardless of where you run. Choosing Cloud takes layer 1 off your back, but it doesn't take away a single one of the responsibilities this guide teaches. That's why the module 1 promise was "this guide doesn't set up the instance": because setting up the instance is layer 1, and operating the workflows is layer 2, which is where you live.

The uncomfortable case: the ERP went down and the customer calls you

Now the case every operator faces sooner or later, and which is the real reason this lesson exists.

The situation. Terra Market's erp —an external system, layer 3, that you don't control— has a two-hour outage on a Thursday afternoon. During those two hours, order-sync can't create orders, because the system it writes to doesn't respond. The orders that come in pile up. A customer who bought an hour ago writes to support: "my order is still processing, what's going on?"

The tempting, and wrong, reaction is: "it's not our fault, the ERP went down, there's nothing we can do." It's tempting because it's true in the half that doesn't matter. Yes, the cause is the erp provider's. No, that doesn't help the customer one bit, and telling them makes them angrier, because to the customer "the ERP" doesn't exist: Terra Market exists, which charged them and didn't deliver.

The correct response separates the two responsibilities:

• The cause isn't yours, and it's fine to acknowledge it internally. Don't flagellate yourself: the erp went down, it wasn't your if. That clarity matters for the retrospective (module 8), where distinguishing cause from response avoids looking for culprits where there are none.
• The response is entirely yours, and there you do have a great deal to do. And this is what separates a mature operation from one that hides behind "it's not my fault":

1. Did you detect the outage fast, or did you find out from the customer? Finding out from the customer is a failure of your response, not the erp's. Good error handling (module 2) and good observability (module 4) alert you to the erp's outage in minutes, before the customer.
2. Did the orders that came in during the outage get lost, or get saved to reprocess? That the erp is down doesn't force you to lose the orders: if order-sync sets them aside in dead_letter when the erp doesn't respond, as soon as the erp comes back they reprocess by themselves or with a click. Losing them would have been your failure; saving them is your merit. The outage was the provider's; the loss or the rescue are yours.
3. Could you tell the customer something honest? "We had a delay with our ordering system, your purchase is recorded and safe, and it will be processed as soon as it's restored —we'll let you know" is a response you can only give if your operation saved the order and knows it saved it. It's infinitely better than "I don't know what happened to your order" or than "it was a provider's fault."

What to expect. The pattern I want you to take: the external system's outage is a fact of reality; your preparation for it is what's judged. You can't prevent the erp from going down —it's not yours— but you can decide entirely what happens to your operation when it goes down. And that decision —detect fast, lose nothing, be able to tell the truth— is exactly what modules 2, 3, 4, and 8 build. The shared responsibility model isn't an excuse to wash your hands; it's a map for knowing that, even if the cause is someone else's, the response is yours, and preparing it.

There's a corollary worth saying out loud, because it's freeing: taking responsibility for the response doesn't mean accepting blame for the cause. You can tell the customer "this was delayed and we're sorry, your order is safe" without lying by saying it was your error, and without blaming a provider the customer doesn't care about. Taking charge of the response is a position of strength, not of apology. The restaurant that says "I'll change your dish right now" is stronger than the one that says "it's just that the supplier…", even if the second is right about the cause.

Documenting the boundary before you need it

None of this works as a reflection; it works as a document. The responsibility boundary is written before the crisis, calmly, to be consulted during the crisis, without debating it.

What the document is. A short table, per external system, that answers in advance the questions that in a crisis become urgent. For Terra Market it would look like this:

RESPONSIBILITY MAP — Terra Market — external systems
Updated: <date>

| System    | Whose it is | How I know it's them | Where I verify it | What I do if it fails |
|-----------|-------------|----------------------|-------------------|-----------------------|
| n8n (Cloud)| n8n runs infra | instance not responding, or platform error | n8n status page | wait + notify; the data is backed up by them |
| erp       | erp provider | 5xx errors / timeouts when calling it | erp panel / their status | set orders aside in dead_letter, reprocess on return |
| carrier   | andes-express | webhooks not arriving / API not responding | carrier status | retry softly; the event may not repeat |
| storefront| store platform | duplicated or missing webhooks | store status | idempotency for duplicates; investigate absences |
| AI provider| model provider | token errors / quota limit | provider status | degrade or pause; spending cap (module 7) |

Notice the columns, because each one answers a crisis question:

• "Whose it is" — so you don't debate it in the moment.
• "How I know it's them" — the concrete signal that distinguishes "the provider is failing" from "my workflow is failing." Without this, every failure starts with twenty minutes of "is it theirs or mine?"
• "Where I verify it" — the status page or panel where it's confirmed. For n8n Cloud, its status page; for the others, whatever each one has. This avoids the trap of assuming the provider failed when the problem was yours.
• "What I do if it fails" — the part of the response that's yours, summarized. It's the seed of the module 8 runbooks.

The honesty rule when filling it in: where you don't know or can't verify a guarantee, write it as "to verify," don't make it up. If you don't know how long the carrier guarantees for its webhooks, the cell says "to verify in their documentation," not a made-up number. An honest map with marked gaps is worth infinitely more than a complete but false one, because the false one gets consulted in a crisis and sends people down the wrong path. This is the same discipline as the lesson 6 inventory: the visible date and the "to verify"s are what make an operational document trustworthy.

Why before and not during. Because during the crisis there's no head-space to draw boundaries: there's a rush, there's an angry customer, there's half the team pointing fingers. The map drawn cold turns that argument into a read. It's the same logic as the inventory and the runbooks: operational documentation work is always done on the calm day for the hard day, because on the hard day it can no longer be done.

Common mistakes

Hiding behind "it's not my fault" (conceptual, the one this lesson fights). What happens: an external system fails, and the operation stops there —"it's not our fault, it's the provider"— without taking charge of the response. The orders get lost, the customer finds out on their own, and the only action is to point at the culprit. Why it happens: responsibility for the cause and responsibility for the response get confused into one, so whoever isn't at fault for the cause believes they have nothing to do. How to catch it: if your plan for an external system's outage is "announce that it was their fault," this is it. How to fix it: always separate the two responsibilities. Yes, the cause was the provider's; and yes, the response —detect fast, lose nothing, tell the customer the truth— is yours and you have a lot to do in it. The restaurant doesn't control the tomato supplier, but it checks the tomatoes.

Making up the provider's guarantees (practical, and dangerous). What happens: someone asserts "n8n Cloud guarantees 99.9%" or "the carrier retries its webhooks three times," without having verified it, and the team builds decisions on that made-up number. The day the number turns out to be false, the decision that depended on it was too. Why it happens: a concrete number sounds more professional than an "I don't know," and the temptation to fill the gap is strong. How to catch it: if your responsibility map has availability figures or provider-behavior figures that you can't point to in their official documentation, this is it. How to fix it: where there's a contractual guarantee, you verify it at the source, you don't remember it. Write "to verify" until you confirm it on the current official page. An honest gap is operable; a made-up number is a trap.

Believing that Cloud takes away this guide's responsibilities (conceptual). What happens: someone chooses n8n Cloud thinking "now operations is their problem" and neglects error handling, credentials, or AI cost, because "it's managed." Months later a workflow loses orders silently, and none of that was configured. Why it happens: "managed" gets misinterpreted as "everything managed," when it only covers layer 1. How to catch it: if your justification for not doing something in this guide is "we're on Cloud, they handle that," verify which layer you're talking about. How to fix it: remember the table. Cloud takes away layer 1 —server, database, backups, updates— and nothing more. Layer 2 —your workflows, their correctness, their credentials, their cost— is yours in Cloud just as in self-hosted, and it's where 90% of this guide lives. Choosing Cloud is a good infrastructure decision; it's not an operation decision.

Exercises

Exercise 1 — Cause versus response. For each of these three Terra Market incidents, separate the responsibility for the cause from the responsibility for the response, and say what concrete action of yours would have improved the response even though the cause wasn't yours.

(a) The AI provider had a one-hour outage and support-ticket-triage didn't classify the incoming tickets. (b) The self-hosted n8n server ran out of memory and restarted, losing the in-progress executions. (c) Your erp credential expired and order-sync stopped creating orders for three hours.

See solution

(a) Cause: the AI provider's (layer 3), not yours. Response: yours. Action that improves it: have support-ticket-triage degrade gracefully when the AI doesn't respond —for example, leave the tickets in an "unclassified" queue instead of losing them, and notify— so that when the AI comes back they get processed. The outage doesn't force you to lose tickets; losing them would have been your response failure.

(b) Cause: ambiguous, and there's the nuance. In self-hosted, the server is layer 1 and it's yours, so running out of memory is, in part, a cause of yours —or of your infrastructure sizing, which the self-hosting guide covers. Response: also yours. Action that improves it: enable saving the execution progress so you can resume, and —more fundamentally— size the server, which is self-hosted layer 1. This case teaches that in self-hosted some "external causes" are actually yours, because layer 1 is yours.

(c) Cause: entirely yours. The credential is layer 2, the most yours of the yours. That it expired without anyone noticing is an operation failure, not a provider's. Response: yours too, and here there's no one to point at. Action that improves it: monitoring the health of the credentials and an alert before they expire (modules 4 and 5). This case is the contrast with the other two: there's no provider behind it, the whole line is on your side, and recognizing it is as important as recognizing when the cause is someone else's.

Why it works: the three cases traverse the three layers —pure external (a), self-hosted infra that turns out to be yours (b), and layer 2 that's yours without debate (c)— and train you not to assume that "something went down" means "it was a provider." Sometimes the provider is you.

Exercise 2 — Draw your instance's line. Write whether your instance (or Terra Market's, which we assume is on Cloud) runs on Cloud or self-hosted, and fill the layer 1 table saying, row by row, whose each responsibility is. Then answer: which responsibilities would change owner if you migrated from Cloud to self-hosted, and which would not change no matter what?

See solution

Assuming Terra Market on Cloud:

The whole of layer 1 —server, n8n's database, updates, instance backups, network security— is n8n's. Layer 2 —the eighteen workflows, their logic, their credentials— is yours. Layer 3 —erp, carrier, storefront, AI provider— is third parties', shared.

If you migrated to self-hosted, all of layer 1 would change owner: the server, the database, the n8n updates, the backups, and the network security would move from n8n to you. That's exactly what the self-hosting guide teaches, and it's real work not to underestimate: backing up the database, applying updates without losing data, sizing the server.

What would not change no matter what are layers 2 and 3. Your workflows would be just as yours, your credentials just as yours, and the erp would keep going down all the same regardless of where n8n runs. That's the point the exercise wants to pin down: the Cloud versus self-hosted decision moves the whole of layer 1 and touches nothing in layer 2, which is where the work of this guide lives.

Why it works: separating what the migration moves from what it doesn't clarifies what's an infrastructure decision (layer 1) and what's a permanent operation responsibility (layer 2). Confusing them leads to believing that changing deployment solves operation problems, which it never does.

Exercise 3 — Write the map of an external system. Choose an external system a workflow of yours depends on (or Terra Market's carrier) and fill its row of the responsibility map: whose it is, how you'd know it failed and not you, where you'd verify it, and what you'd do if it fails. Honestly mark with "to verify" everything you can't confirm today, and say how many cells you left to verify.

See solution

Let's take the carrier (andes-express), the most unstable of Terra Market's:

• Whose it is: andes-express's, the shipping carrier's provider. Layer 3.
• How I know it's them: the status-change webhooks stop arriving, or the calls to their API to generate labels time out or error. The signal that distinguishes it from a failure of mine: if my workflow is fine but the carrier's responses don't arrive or arrive with an error, it's theirs.
• Where I verify it: "to verify" —I'd have to confirm whether andes-express publishes a status page, and which one. I'm not going to make it up. Until I confirm it, the cell says "to verify: do they have a status page?"
• What I do if it fails: retry softly (not aggressively, because an unstable carrier can get worse with retries), and —key— keep in mind that the carrier may not repeat a lost event, so a shipment notice that was lost during their outage may have to be reconstructed by querying the shipment's current status when the carrier comes back. This is pure response responsibility: the outage was theirs, but recovering the lost notices is mine.

Cells to verify in this example: at least one (where to verify their status), and probably more if I'm honest about which of the carrier's guarantees I actually know. And that's fine: each "to verify" is a concrete task, not a shame.

Why it works: the exercise forces the discipline of the lesson —not making up guarantees— exactly where it's most tempting to fill the gap with a nice-sounding number. Ending with honest "to verify" cells is doing it right, not doing it halfway. And the last column, "what I do if it fails," is literally the first draft of a module 8 runbook.

Summary and next step

In this lesson you drew the line. With the image of the restaurant and the tomato supplier the module's thesis about the external landed: responsibility for the cause is shared, but responsibility for the response is yours, and the customer doesn't distinguish the two —they call you no matter what. You saw the three layers of responsibility: the infrastructure (layer 1), which is n8n's in Cloud and yours in self-hosted; your workflows and credentials (layer 2), which are yours wherever you run; and the external systems (layer 3), which are third parties' in both cases. With honesty about the provider, you verified what n8n Cloud does cover —regular backups, per-plan retention, a status page— and refused to make up what you couldn't confirm: no availability number or SLA clause without verifying it at the current official source. You faced the uncomfortable case —the erp went down and the customer calls you— and learned that taking on the response isn't accepting the blame: it's detecting fast, losing nothing, and being able to tell the truth, which is a position of strength. And you learned to document the boundary before you need it, with a map per external system whose honest cells say "to verify" instead of lying.

Before moving on you should be able to: explain the difference between responsibility for the cause and for the response with the restaurant example; say which layer changes owner between Cloud and self-hosted and which never changes; and fill the map of an external system honestly marking what you can't verify.

Lesson 8 is the project, and it brings the whole module together into a single deliverable. You're going to audit Terra Market's eighteen workflows: classify them with the matrix from lesson 3, run the calibrated checklist from lesson 4 on them, have them named and inventoried as in lesson 6, with their responsibility map from this lesson, and deliver a report with the three workflows that need fixing first and why. That report isn't an exercise that gets filed away: it's the work plan for the seven modules that follow. When you finish it, you'll know exactly where to start operating Terra Market for real.

Resources

• Cloud data management — n8n Docs — what n8n does with your data in Cloud: regular replicated and encrypted backups, and the per-plan execution-data retention. The verified source for layer 1 responsibility in Cloud.
• Deploy n8n — n8n Docs — the comparison between n8n Cloud (managed by n8n) and self-hosted (control and responsibility yours), which is exactly this lesson's layer 1 line.
• Security — n8n — n8n's official security page, where its practices are documented. The place to go when you need to verify a guarantee instead of making it up.
• Manage your data — n8n Docs — how to manage your data in Cloud, including retention, to know how far you can look back.
• n8n status — the n8n Cloud platform status page. The first place to verify whether an incident is n8n's and not yours. Remember: each external provider has (or doesn't have) its own; verify it, don't assume it.