An Airtable automation failed or did not run: read the history, then check five causes

Read the history before you change the automation

Open the base, choose Automations, pick the automation and open its history. Airtable's troubleshooting article shows four statuses: ran successfully, pending, run cancelled and failed run. Open a failed run and expand its error message, and note which action failed and what the error says. One trap is worth knowing at once: a rerun uses the configuration the run first started with, not your latest fix, so rerunning is not a test of a repair. Trigger a fresh run on a test record instead.

• Record the action that failed and the exact error text.
• Note whether the run was cancelled because someone switched the automation off while it was pending.
• Retest the trigger and each action separately on a record that meets all the conditions.

Why some records never trigger

Triggers fire on a change, not on a state. Airtable says that records already meeting the conditions when you switch an automation on will not trigger it unless they satisfy the conditions again. A trigger for a record entering a view fires each time a record re-enters that view, and restoring a deleted record can fire triggers too. Several automations triggered at once have no guaranteed order. If a batch of old records was expected to run and none did, this is the first thing to check. The fix is usually to cause the change deliberately, for example by moving the field away from and back to the matching value on a test record, or to run the old records through a separate one-off step.

Inputs that resolve to nothing

Most failed runs trace to an action input with nothing in it. The article lists an email recipient that resolves to nothing, such as an empty linked record or a computed field that has not calculated yet; a number field that receives typed maths; an attachment that was not finished processing when the automation fired; permission limits on a field or table; and a formula primary field in a linked table. Adding an is-not-empty condition on the fields an action depends on stops some of these runs from starting at all. That also means some records will deliberately not run, so list them rather than letting people wonder.

Scripts, limits and slots

A script action has a 30-second network timeout described in the article, which large tables, long loops and slow fetch calls can hit. The suggested remedies are to request only the fields you need, to use a repeating group instead of one large loop, and to batch updates. Airtable also meters runs: the pages checked on 11 October 2026 state monthly run limits of 100 on the free plan, 25,000 on Team, 100,000 on Business and 500,000 on Enterprise Scale for each workspace, reset on the first of the month, and say that failed runs count as well as successful ones. A base also has a cap on the number of automations, and switching one off does not free its slot, only deleting does. Plans change, so confirm the numbers for your own account.

• Check the workspace's usage before a test that will cause many runs.
• Count automations that are switched off but still take a slot.
• Keep scripts short, and test against your largest table.

Who is told when it fails

Airtable sends the failure email to the person who last turned the automation on. If that person has left the workspace, workspace owners are notified. Extra subscribers can be added, but they need Creator permission or higher on the base. The article also says an automation can switch itself off after an authentication change, such as a password update on a connected third-party account, and has to be reconnected under Manage connected accounts. If the one person who gets the emails ignores them, nobody knows.

What this guide does not cover

This guide does not raise plan limits, reconnect accounts or restructure a base. The paid outcome repairs one automation of up to five actions on a duplicate base, proves three agreed cases and one deliberate failure with an alert to a named person, and reports how many of your monthly runs the tests used. A separate outcome splits a repetitive table into linked tables, and a standing service watches named automations and prepares corrected copies for you to apply.