A loud failure feels like a solved problem. When a request is rejected with an HTTP 429, or a validation check holds a record back, something has clearly gone wrong, and a signal exists. But a signal only helps if it reaches someone who can act on it. In a multi-system landscape, each signal goes wherever the system that produced it sends signals, and that's often not where the person who can fix the problem, or the person relying on the data, is looking.
This post turns a question from InAir's guide to operating Airtable inside complex system landscapes [PILLAR 2], "visible to whom?", into a method for connecting each type of failure to a named owner. Failure visibility is one of the five factors in InAir's Integration Load framework, and this post covers the part of it that's easiest to overlook.
In a single system, the person who sees an error is usually the person who can fix it. In a connected landscape, that stops being true. Three different people are typically involved, often in different departments:
The operator carries the most risk and has the least visibility. When a sync from the CRM is throttled, the interface still shows a record. It's just an older version of it, and nothing on the screen says so.
Before assigning ownership, it helps to map where each type of failure actually reports. Most landscapes have at least these four:
A few details in that table are worth knowing precisely.
Rate-limit rejections stay with the sender. Airtable allows 5 requests per second per base. A request over that limit gets a 429, and the sender has to wait 30 seconds before its requests succeed again. The rejection is returned to the system that sent it, and it isn't shown to anyone working in the base.
Airtable automation failures go to specific people. By default, a failed Airtable automation emails whoever turned it on. If that person has left the workspace, the email goes to every workspace collaborator with owner permissions instead. Neither may be the one who should act on it, so add subscribers. A subscriber needs Creator permissions or higher on the base (troubleshooting guide). Each automation takes up to 10 subscribers, and adding a service account lets a distribution list receive the alerts. Failure notifications only go out while the automation is on (managing automations).
That has a practical consequence. The interface operators who depend on the data usually don't have Creator permissions, so they can't be subscribed individually. A distribution list can reach them, but it sends that automation's failure emails to everyone on the list, whether or not a given failure affects their work.
Quiet disagreements have no signal at all. They're a different problem, covered in building a cross-system agreement check. This post deals with failures that do produce a signal that doesn't reach the right person.
A failure that's logged somewhere has a record, not an owner. Ownership means a specific role is responsible for acting on a specific type of failure, and everyone knows which role that is.
Assign ownership by role, not by person, and give each role a backup. People change jobs, go on vacation or leave. If ownership sits with one named individual, it disappears when they do. Airtable's own behavior shows the risk: when the person who turned an automation on leaves the workspace, its notifications go to all workspace collaborators with owner permissions. A message sent to everyone is easy for each person to assume someone else will handle.
The roles here are examples. The point is that every row has one.
Once each failure type has an owner, the signal needs to reach them without anyone going looking. The aim is to move the failure out of the place it happened and into the place the owner already works.
Inside Airtable, three patterns cover most cases:
For failures that happen in another system, like a 429, the fix sits in that system's error handling. It should notify the owning role directly, or record the failure somewhere the owner watches.
Good routing also decides what not to send. A single 429 doesn't need a person, because Airtable asks the client to wait 30 seconds and the retry usually goes through. A write that's rejected on every attempt does need one. Microsoft's Retry pattern draws the same line between transient faults worth retrying and faults that are unlikely to succeed if repeated. Alert on both, and the real failures end up buried among alerts that already fixed themselves, until the owner stops opening any of them.
This test checks whether each failure actually reaches its owner, not just whether a signal exists somewhere.
This goes a step beyond the failure-visibility check in the Integration Load Scorecard. That check asks whether anything surfaces a failure. This one asks whether it reaches the person who's supposed to act on it.
A loud failure is better than a silent one, but only if someone hears it. In a connected landscape, the system that detects a failure, the person who can fix it, and the person affected by it are often three different parties. Closing that gap takes three things: know where each failure reports, assign every failure type to a role with a backup, and route the signal to where that role already works.
If you want to map where failures in your landscape actually go, and make sure each one reaches someone who can act on it, that's the work InAir does. Schedule a Discovery Call with InAir to find out what your integrations are actually carrying.