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.