Most Airtable automations that stop working are not broken — they were never triggering in the first place. The usual causes are a workspace that has burned through its monthly run allowance, a trigger that fired before your data finished saving, or an automation that quietly switched itself off after a connected account lost its authorisation.
The fastest way to tell those apart is the run history, and the fastest way to waste an afternoon is to start rewriting the automation before you have read it.
Read the run history before you change anything
Every automation keeps its own log, and it records live runs only — the tests you ran during setup never appear there. If the log is empty, the automation has never actually fired, which is a completely different problem from a run that fired and failed.
- Open the base and click Automations.
- Select the automation from the Automations list.
- Click Automation history, then Run History.
- Filter the runs by status, or leave it on All if you are not yet sure the automation fired at all.
- Click the > arrow next to a run, then the > arrow next to the step showing a fail count, to expand the error message.
Airtable documents four run statuses: Ran successfully, Pending, Run cancelled and Failed run. There is no “Skipped” status, despite how often you will see one described in troubleshooting write-ups. If a conditional group’s actions did not execute, that run still reports as successful — the automation did exactly what you told it to, which was nothing. Check the group’s conditions against the actual record values, and remember that only one conditional group runs per invocation: the first one whose conditions match wins, even if a later group also matches.
You will also see confident percentages quoted about how many problems the log resolves. Airtable publishes no such figure. Treat any number like that as decoration.
Check your run limit before you debug the logic
This is the single most common cause of an automation that “just stopped” with no error to show for it. Run limits are per workspace, per month, and they reset on the first of the calendar month — not on your billing date. Crucially, Airtable counts a run each time a trigger is invoked, so failed runs burn allowance exactly like successful ones. A looping automation can strip a month’s quota in an afternoon.
| Workspace plan | Automation runs per month | Run history retained | Non-collaborator emails per day |
|---|---|---|---|
| Free | 100 | 2 weeks | None — recipients must be base collaborators |
| Team | 25,000 | 6 months | 100 |
| Business | 100,000 | 1 year | 1,000 |
| Enterprise Scale | 500,000 | 3 years | No limit |
Those four tiers are the current lineup. If you find advice referring to caps on a “Plus” plan, it is describing a plan Airtable retired — the guidance may be years stale, and so may everything else in that article. Our breakdown of Airtable pricing by plan covers where the other ceilings sit.
Two things trip people up here. First, the limit belongs to the workspace, so a base sitting in a personal Free workspace is metered at 100 runs even if your organisation pays for Enterprise Scale. Second, the Run a script action is unavailable on Free entirely, so a script-based automation copied from a tutorial will simply not be buildable. To confirm usage, open your Airtable account overview, select the workspace, and read the Usage tab. Workspace owners get warning emails at 80%, 90% and 100%.
If you are regularly close to the ceiling, the fix is architectural rather than financial. Consolidating several single-purpose automations into one, or moving bulk work into a repeating group, cuts invocations sharply — the approach is covered in our guide to building Airtable automations without wasting runs.
Your trigger fires earlier than you think
A persistent piece of folklore holds that Airtable evaluates trigger conditions when a record is “saved”. Airtable has no save button, and the documented behaviour is close to the opposite: the When a record is created and When a record is updated triggers fire as soon as the first few characters are typed into the record. Your automation reads a half-filled record and either fails on a missing value or writes something wrong.
Three related timing traps account for a large share of “it works in testing but not live” reports:
- Computed fields lag. A Send an email action that fails with “To input is empty” on live runs but passes every test is almost always reading a formula, lookup or rollup that had not finished calculating. Test runs use a record that is already fully populated, so the address resolves. Map the recipient to a plain email field, or insert a Find records step ahead of the email action to re-fetch the record.
- Formula fields do not trigger instantly. Automations watching a formula field fire roughly every five minutes while someone has the base open, and about once an hour when nobody does.
- Attachments trigger on upload start, not upload finish. Airtable begins processing a file immediately, but the automation can fire before processing completes. Large files and simultaneous uploads are the worst offenders. Adding a delay helps but does not guarantee the file is ready, so treat delay-based workarounds as mitigation rather than a fix.
One more documented behaviour worth knowing: automations never run retroactively. Turning one on does not sweep up records that already match the conditions. Those records have to stop matching and then match again — uncheck the box, recheck it — or be pushed through the Batch update extension.
Automations that switch themselves off
An automation flipping from On to Off on its own is nearly always an authentication problem, not a platform fault. Airtable documents two causes: an expired or changed credential on a connected third-party account (Google Workspace, Jira, Microsoft Teams and similar), and a Google Drive automation pointing at a file held in a shared or team drive, which Airtable cannot reach. Reconnect through Manage connected accounts inside the action step.
What Airtable does not document is any mechanism that auto-pauses an automation after a run of consecutive failures. That claim circulates widely, but it appears nowhere in Airtable’s documentation. An automation that fails repeatedly keeps failing — and keeps consuming runs — until someone turns it off. Likewise, claims about specific undated platform incidents silently disabling automations should be checked against Airtable’s own status page rather than taken from a blog post.
Failure notifications go only to the last collaborator who toggled the automation on, which is why a departed colleague’s automation can fail for weeks in silence. Open the dropdown next to the automation name, choose Manage subscribers, and add up to ten owners, creators or service accounts. Do this on anything business-critical.
Interface buttons: what actually restricts “Run automation”
Another myth in circulation is that button-triggered automations only work in Grid or Gallery interfaces and that the List layout cannot run them. That is wrong in both directions. Airtable’s documentation on using buttons in interfaces lists List, Grid, Gallery, Kanban, Calendar, Timeline, Swimlanes, Record detail and Record review as layouts that support buttons at all. The real constraint is on the action: Run automation is documented as available on record detail and record review layouts specifically, alongside actions like Update record and Delete record. Grid and Gallery pages get the navigation actions, not the automation one.
Setup order matters too, because the automation and the button each depend on the other existing:
- In Automations, create the automation with the When a button is clicked trigger and leave it turned off — it will refuse to enable without a connected source.
- In Interface Designer, open User actions, then Buttons, add a button, set the action to Run automation and select the automation you just made.
- Return to Automations and toggle the automation on. The trigger requirement is now satisfied.
Note also that read-only and commenter users cannot click a Run automation button at all. If one person reports the button doing nothing, check their permission level before you check the automation.
Ceilings that truncate quietly
Repeating groups are where large jobs fail without an obvious error. A Find records action returns a maximum of 1,000 records per run, and a repeating group’s input list caps at 8,000 items. Exceed either and you get a partial result, not a failure — the automation reports success having processed a slice of your data.
The upside is that a repeating group counts as one run regardless of how many records it touches, which makes it the best tool available for staying inside a run limit. The trade-off is real: once an automation contains a repeating group, the Test automation button is disabled and you can only test steps individually.
Field agents are a separate system
Field agents — Airtable’s AI-powered fields — are frequently blamed for automation failures they have nothing to do with. They are fields, not automations. They consume AI credits rather than automation runs, they require a paid plan, and they need AI enabled at the workspace level before they appear at all. If a field agent is producing nothing, check credits and workspace AI settings first; our walkthrough of setting up Airtable Field Agents covers the configuration in detail.
Two documented limitations cause most of the confusion. Field agents are blocked from reading files in a personal Google “My Drive” and will report finding no files; move the folder to a Shared Drive. And the Run automatically setting makes an agent regenerate whenever its inputs change, which can cascade through dependent formulas and automations and quietly inflate both credit and run consumption.
Frequently asked questions
Why does my automation work in testing but fail on live records?
Testing uses a record you chose, which is already complete. Live triggers fire the moment editing starts, so formula, lookup and rollup fields may not have calculated yet. Map actions to plain stored fields, or add a Find records step before the failing action to re-read the record.
Do failed runs count against my monthly limit?
Yes. Airtable counts a run each time a trigger is invoked, regardless of whether the actions completed. A failing automation consumes exactly the same allowance as a working one, which is why a looping automation can exhaust a month’s quota within hours of being switched on.
Why didn’t my new automation run on existing records?
Automations only apply from the moment they are turned on. Records that already met the trigger conditions are ignored. To include them, change each record so it no longer matches, then change it back — or push the change through the Batch update extension instead of editing manually.
Can I rerun a failed automation after fixing it?
You can click Rerun on any past failed run, but it executes using the configuration that existed when the run first happened, not your corrected version. If the rerun keeps failing, trigger the automation fresh using a manual trigger such as a checkbox field or an interface button.
Is the problem Airtable or my base?
Almost always the base. Before assuming a platform fault, confirm the automation is toggled on, check the run history for an actual error, and verify your workspace has runs remaining. If several unrelated bases stop at once, then check Airtable’s status page.
If you are troubleshooting the same class of problem on other platforms, the patterns differ more than you would expect — our notes on Notion automation failures and ClickUp automation troubleshooting cover those. For the wider picture on where Airtable’s automation engine sits against its competitors, see our Airtable review. Airtable’s own troubleshooting reference and its automations overview with the current run limits are the two pages worth bookmarking.
Sponsored
Related guides
