The automation run limit nobody reads
Airtable's own documentation says it plainly: the system counts an automation run each time a trigger is invoked, whether or not the actions ran properly. Failed attempts spend from the same allowance as successful ones. On the Team plan that allowance is 25,000 runs a month for the entire workspace. Most teams never read the number until the month a build stops running.
The meter counts attempts, not results
A run is a trigger firing. Airtable's automations documentation, updated a month ago, states that both failed and successful attempts count against the workspace's monthly allowance. So does a webhook that arrives twice. So does an automation that fires, checks a condition, decides there is nothing to do, and exits.
Formula fields make this worse in a way that is easy to miss. Airtable's own FAQ says automation triggers on formula fields evaluate roughly every five minutes while a base is loaded by a user, and once an hour when it is not. One formula-driven automation on a base your team keeps open all day has a floor of runs that has nothing to do with how much work actually happened. Nobody budgets for that, because nobody thinks of an idle browser tab as consumption.
When you reach the cap, Airtable's pricing FAQ is direct about what follows: for automations and API limits, you are capped at the usage limit on your current plan. Records behave differently, and your data stays put, but the automations stop. They resume on the first day of the next month, when limits reset. If your invoices, your onboarding emails, or your inventory sync ride on those runs, the calendar decides when they come back.
Capacity billed as headcount
The next tier up is Business, which raises runs from 25,000 to 100,000. Airtable prices Team at $20 per seat per month billed annually, $24 monthly, and Business at $45 per seat per month annually, $54 monthly. A workspace with twelve editors pays $240 a month on Team and $540 on Business. That is $3,600 more per year, and the thing you bought was run capacity, not anything the other eleven people needed.
Splitting the load across bases does not help, because the ceiling applies per workspace and the Team plan includes exactly one workspace. Unlimited workspaces start at Business, which is the tier you were trying to avoid paying for. The same shape shows up in the email action: Team automations can reach 100 unique non-collaborator addresses a day, Business 1,000. A customer notification flow that outgrows 100 recipients a day is a pricing event.
I want to be fair to Airtable here. Per-seat pricing is honest for what Airtable mostly sells, which is a place where non-engineers edit structured data together. It stops being honest for your use case the moment the seats stop growing and the runs keep going, because then you are buying a machine resource with a people meter.
What the runs were actually doing
Look at a mature Airtable automation set and most of it is ordinary backend work. Write a row when a form comes in. Call an external API. Send a templated email. Recompute a status when a linked record changes. In a Next.js or NestJS service each of those is a function with a test around it, running on infrastructure where a retry costs CPU milliseconds and nothing else.
That is the part teams underestimate when they move. The data is the easy half. For Stay World Class we replaced Webflow and Xano with Next.js, NestJS and Supabase, and the migration hinged on a four stage ETL that mapped every legacy identifier to a PostgreSQL UUID so nothing pointed at a record that no longer existed. Lighthouse went from 55.91 to 91 out of 100 and LCP came down 77 percent. The database load was scriptable. The accumulated automation logic was the part that needed a human to sit down and read it.
Once that logic lives in your repository, the monthly ceiling stops existing as a concept. There is no run counter. There is a bill for compute, which scales with actual traffic rather than with how many times a formula field woke up.
When staying on Airtable is the right answer
If you are running a few thousand automation runs a month on Team, you have headroom for years and there is nothing here for you to fix. The 25,000 number only bites teams who made Airtable load-bearing, which is a sign the tool worked.
The stronger reason to stay is the one people skip past. Airtable's real product is the editing surface, and it is very good. If your operations team lives in that grid all day, adds fields without asking anyone, and builds their own views, replacing it means replacing the interface too, not just the automations. A Postgres database gives you none of that for free, and an internal admin panel that feels as good as Airtable is real work.
The case for moving gets clear when three things are true at once: the run count is driving the plan choice rather than the seat count, the automations encode business rules nobody can test, and someone on your side can own a deployment. If only one of those is true, stay where you are and revisit it next year.
