Pricing and usage limits for automations

Different usage limits for Automations depend on your Airtable plan. See the screenshot below for a quick highlight, or visit airtable.com/pricing for more details.

I think this is a mistake. Here’s why…

  • Automations based on events are vastly less server-intensive than polling architectures - the likes of which most integrations have been built on thus far.
  • Polling processes designed to mimic event processing is vastly employed by the no-code glu-factories like Zapier and Integromat and they drive massive request traffic to your API servers. Ideall, you want users to stop doing this.
  • Capping automation executions is a disincentive to leave the polling processes and move to the new model.
  • Native Airtable automations generally require script; charging customers more money to utilise script-based integrations and automations is yet another disincentive to adopt the highly performant event-based automation features.

In my view, all scripting mechanisms should be free from disincentives/restrictions and event-based automations should be openly embraced without any constraints because it actually costs less for Airtable to support this fundamental shift.

If Airtable truly wants a slice of the pie based on micro-transactions, then build that revenue model; don’t force users to jump payment tiers just to be able to run 5001 event transactions.

1 Like