Airtable's free plan allows exactly 100 automation runs a month, and every one of those runs counts the moment a trigger fires, whether the automation finishes successfully or fails halfway through, according to Airtable's own plans overview. That number sounds generous until a base with three or four live automations starts firing on every new record, every status change, and every form submission across a busy week.
Most Airtable automation guides walk through triggers, conditions, and actions, then stop. They do not explain what actually happens the week a workspace quietly runs out of runs, or why a native automation that looked finished in testing starts failing silently in production. That gap is the actual decision point for anyone running a business on Airtable past the hobby stage.
TL;DR:
- Airtable's automation run limits are 100/month on Free, 25,000 on Team, and 100,000 on Business, with Enterprise Scale negotiated separately, and failed runs count the same as successful ones.
- Native automations have no automatic retry. A failed run needs a human to notice it and click Rerun.
- Airtable's API itself caps at 5 requests per second per base, which limits how fast a script action or external tool can work with the same base.
- The real decision is not whether to use Airtable automation. It is when to graduate a specific workflow to a dedicated automation platform.
How Airtable automation actually works
Every Airtable automation follows the same three-part shape: a trigger, an optional condition, and one or more actions.
- Trigger: a new record, an updated field, a scheduled time, a webhook, or a button click.
- Condition: an optional filter that decides whether the automation should continue.
- Action: send an email, update a record, create a record in another table, call a webhook, or run a script.
That structure covers a lot of real work. Routing new form submissions to the right team, sending a reminder when a due date passes, or syncing a status change into a linked table are all a few minutes of setup inside Airtable itself, no external tool required.
The run-limit math nobody shows you
Airtable's automation run limits scale with the plan, and the numbers are public on Airtable's plans overview page:
- Free: 100 runs per month, 75 unique automations per base
- Team: 25,000 runs per month, 100 unique automations per base
- Business: 100,000 runs per month, 150 unique automations per base
- Enterprise Scale: Airtable does not publish a fixed number on its plans page. The run allowance is negotiated directly with Airtable's sales team as part of the enterprise contract.
The limit applies per workspace, not per base, so every automation across every base in that workspace draws from the same pool. A workspace with five active bases, each running a handful of automations, can exhaust a Free or even a Team allowance faster than the per-base numbers suggest.
The detail that catches most teams off guard is how a "run" gets counted. Airtable counts a run the instant the trigger fires, before anything downstream happens. A broken automation that keeps triggering on the same bad data, or a condition that is slightly too broad, burns through the allowance at the same rate as one that is working exactly as intended.
Why native automations break at scale
Three limitations show up repeatedly once a workflow grows past a single trigger-condition-action chain.
No automatic retry. Airtable's own troubleshooting documentation is explicit that a failed run requires a manual click on Rerun, and that the rerun executes the automation's configuration exactly as it stood at the time of the original failed run, not any fix made since. A transient failure, like an external API being down for thirty seconds, needs a person to notice it and act, because nothing in Airtable retries it automatically.
No rollback on partial failure. If a multi-step automation fails on step three of five, the first two steps already happened. Airtable does not undo them. A workflow that creates a record, sends a notification, then fails while updating a linked table leaves the base in whatever partial state the first two successful steps left behind.
A hard API rate ceiling. Any script action, or any external tool reading from or writing to the same base, shares Airtable's published rate limit of 5 requests per second per base. Exceed it and the API returns a 429 error, with a mandatory 30-second wait before the next request succeeds. Batching helps, since a single batched create, update, or delete request can cover up to 10 records, but the ceiling itself does not move.
None of these are bugs. Airtable's automation engine was built for straightforward, single-path workflows inside one base, and it does that well. The limitations show up specifically when a workflow needs branching logic, calls to several external systems in sequence, or recovery behavior when something downstream fails.
When to graduate the workflow, not the whole base
The decision in front of most Airtable users is not "replace Airtable." It is "which specific automation has outgrown what Airtable automations do well."
A workflow is a good candidate to move to a dedicated tool like n8n, Make, or Zapier when any of the following is true:
- It needs to call more than two or three external APIs in one chain.
- A failure needs automatic retry with backoff, not a human clicking Rerun.
- The logic needs real branching: if this, then one of several different paths, not a single linear sequence.
- Run volume is approaching the plan's monthly cap and upgrading the whole workspace plan costs more than routing just that one workflow elsewhere.
Our workflow automation team builds this kind of migration regularly: Airtable stays the database and the interface the team already knows, while the automation logic that needs retries, branching, or multi-system orchestration moves into n8n or Make, connected back to Airtable through its API. The comparison in our n8n vs Make vs Zapier guide covers how to pick between those three once a workflow reaches that point.
The same logic applies to Airtable's newer AI-powered fields and agentic automation features. They are genuinely useful for judgment calls inside a single base, like classifying a record or drafting a summary. Once that judgment needs to combine data from multiple systems or make a decision that feeds back into other tools, it usually works better paired with a dedicated AI automation layer built to handle that complexity, rather than stretching a single Airtable automation to do both the AI reasoning and the cross-system orchestration.
The decision rule
If an Airtable automation has ever needed a human to notice a failure and manually click Rerun, that is the signal it has outgrown native automation, not a reason to add another condition and hope it does not happen again.
The next concrete step is a short audit: pull up each base's automation history, filter by failed runs, and count how many needed a manual rerun in the last 30 days. Any automation with more than one or two manual reruns is a strong candidate for a rebuild in a tool with real retry and error handling built in. If that audit turns up more than a couple of candidates, that is the right moment to book a scoping call with a team that builds workflow automation for a living instead of patching the same Airtable automation a third time.
