Job airtable-automation-fails-or-skips-records · revised 11 October 2026
Make one Airtable automation run on the records it should
Synthetic records covering three agreed cases make one Airtable automation run successfully or skip deliberately as documented, and a failed run reaches a named person.
You might be seeing
- The automation history shows Failed run with an error message on one action
- Some records trigger the automation and similar ones do not
- A notification email goes to nobody because its recipient field was empty
No passwords, keys, card details or admin invites needed to start.
What usually happened
An Airtable automation can fail or skip records for several documented reasons: an action input that resolves to nothing, such as an empty linked record in the recipient field; a trigger that only fires when a record starts matching its conditions, not for records already matching when it was switched on; a script that exceeds the 30-second network limit on a large table; an attachment that has not finished processing; or an automation switched off after an authorisation change. The job finds which applies to one automation and repairs it on test records.
Who it’s for: An operations manager or small-business owner who runs a process from an Airtable base and whose automation shows failed runs or does not fire for some records.
Usually starts when: Notification emails stopped, a status change did nothing, or the automation history shows failed runs that nobody looked at.
The result: With synthetic records for three agreed cases, one named automation either runs successfully or skips as the note documents, history shows Ran successfully for the cases meant to run, and a deliberately failing case produces an alert to the named person.
Check whether this job fits
Answer these from the automation's history without sharing record data or logins. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
Read one failed run
In the base, open Automations, choose the automation, open Automation history and expand one failed run and its error. Do not use Rerun to test a fix, because a rerun uses the configuration the run started with.
Look for: Which action failed, the error text, whether an input was empty, and whether the record already matched the trigger conditions.
What you get
- A short note naming the cause, with the relevant history entries redacted
- The repaired automation, with change notes and how to reverse them
- A test log: the three cases, expected behaviour, history status and run count used
- A list of conditions under which the automation will legitimately not run, in plain words
Included
- One automation in one base, with its trigger and up to five actions read in full
- Diagnosis from the automation history of why runs fail or records are skipped
- Repair on the trigger conditions, an action input, or one short script, and add an 'is not empty' condition on inputs where that is the cause
- Test three agreed cases on test records, and one failing case to prove the alert reaches the named person
- A maximum number of test runs, written into the quote at scoping and set from the three cases, the failing case and any rerun you accept, then checked against what is left of your workspace's monthly run allowance
Not included
- Raising your plan's automation run limits or per-base automation limits, or reconnecting third-party accounts, which the account holder does
- More than one automation, or rebuilding the base or its views
- Restructuring tables or fields, which is a separate job
- Scripts beyond one short script action
- Real customer records or any message sent to a real recipient during testing
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
For each of the three agreed test cases, the automation either shows Ran successfully in its history with the intended effect, or is documented in the note as deliberately not running for that case.
Evidence: The automation history entries, redacted, and the test log.
A deliberately failing case produces a failure notification to the named person, and that person is recorded as a collaborator with Creator permission or higher who is subscribed to it.
Evidence: The received notification and the notification subscriber list with the person's permission level.
The number of runs used by the tests is recorded and does not exceed the maximum number of test runs written into the quote at scoping.
Evidence: The run count in the test log beside the agreed maximum.
The change notes list each altered setting with its earlier value and name every condition under which the automation will not run.
Evidence: The change notes.
Sign-off. You inspect the history, the received alert and the change notes, then sign off before payment. You apply the repair to the live base and check one genuine record.
If it fails. If the agreed tests do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- You are an owner or creator in the base and can edit the automation, and can make test records
- The base has headroom in your workspace's monthly automation run allowance for the agreed maximum number of test runs, which count whether they succeed or fail
- Outgoing email or app actions on the automation can be pointed at a test recipient for the duration of the test
- The person to receive the failure alert is a collaborator with Creator permission or higher on the base, because Airtable only lets such collaborators be added as notification subscribers
We stop and tell you if
- The automation stopped because a connected account's authorisation changed and only the account holder can reconnect it
- The workspace has used its monthly automation run allowance, or has too little left for the agreed maximum number of test runs
- The person to be told cannot be given Creator permission or higher on the base
- The cause is a formula primary field or a synced table that you do not want changed
What could go wrong
All changes are made on a duplicate base. The live automation is untouched until you copy the change across. Change notes list each altered setting with its earlier value, so you can restore it.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Test runs use up part of your monthly automation run allowance. | Airtable counts failed and successful runs. We keep the tests to the maximum number of runs agreed in writing at scoping and report the number used. |
| A condition added to stop empty inputs makes some real records skip silently. | The note lists exactly which records will not run, and the failing case proves the alert for genuine failures. |
| A script change slows or breaks on a large table. | Keep scripts short and request only the fields needed; the test includes the largest table the automation reads. |
An independent reviewer checks the redacted before and after evidence, that every test used synthetic data, that nothing outside the agreed scope changed, and whether your authorised owner can safely reverse the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the automation, the three test cases, the failure alert recipient, the maximum number of test runs and the test route in writing
- Read the trigger, each action and the redacted history entries, working on a duplicate of the base
- Reproduce the failed or skipped case on synthetic records, using a fresh run each time rather than a rerun
- Repair the cause with the smallest change: condition, input mapping or one short script
- Run the three cases and one failing case; record the history status, run count used and the received alert
- Independent review of the changes and of what the automation would now do to live records, then hand over the notes; you apply it to the live base
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform, hosting and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If this base runs daily operations, discuss ongoing monitoring of its automations as a separate recurring service.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Airtable's troubleshooting article lists common failure causes, how to read automation history and why a rerun does not test a fix. Your base owner may resolve it from there. support.airtable.com
- Airtable support can investigate failed runs that its troubleshooting steps do not resolve.
Questions
Why did the automation not run for records that already matched?
Airtable documents that records already meeting the conditions when an automation is switched on do not trigger it until they satisfy the conditions again. The note will say whether that applies.
Who gets told when it fails?
Airtable sends the failure notice to the last person who turned the automation on, and to workspace owners if that person has left. We add a named person to the alert as part of the job; Airtable only accepts a collaborator with Creator permission or higher on the base as a subscriber.
Will testing cost me runs?
Yes, a few. Airtable counts failed and successful runs. We agree a maximum number of test runs with you in writing before testing, keep to the agreed cases and report the number used.
Send an enquiry
Send us
- The base and automation names, the trigger type and the action that fails, with its redacted error text
- Whether the failing record has an empty linked field, an attachment or a large table behind it
- Who last switched the automation on
- Do not send record exports, passwords or a base invitation in the first enquiry
Later, once you agree
- An editor or creator invitation to a duplicate of the base, made without its records where the failure can be reproduced that way, or a screen-sharing session you run, which you can revoke
- Three described test cases and test recipient addresses you control, and your written agreement to the maximum number of test runs
- A named person to receive the failure alert, who is a Creator-or-higher collaborator on the base
- A secure handover route for the duplicate base, agreed with you in writing before any access; none exists in advance, and the first enquiry carries no records
You keep the live accounts, production keys and customer records. We work only on a copy or a test route with synthetic data, through a company-controlled handoff agreed before any access; a person owns Synthetic Industry and remains accountable. Your authorised account holder approves and carries out the live change.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “airtable-automation-fails-or-skips-records” as the subject.