Help

Re: Maximum Number Of Automations

5064 4
cancel
Showing results for 
Search instead for 
Did you mean: 
Joseph_Wheeler
5 - Automation Enthusiast
5 - Automation Enthusiast

Hey Everyone,

As someone who was previously using a lot of Airtable to Airtable automation through Zapier I jumped on the new built in Airtable Automation features. However I’m now having issues where I can’t create any new automations due to exceeding the maximum number of automations for the base. I can’t find any information on what the maximum amount actually is or if there is an option to increase this.

I love this feature but I’m now at a dead end where I can’t use it further, I can’t see how to increase my usage and I can’t see how much this has been exceeded by.

Any help from the community or from the Airtable team is greatly appreciated.

22 Replies 22

I think the CPU time ceiling only applies to scripting actions. Plus, the time limit is per action—each scripting action starts off with a clean slate—the time spent on prior actions doesn’t matter. I’ve had an automation run that can take a couple of minutes to complete (mostly waiting on a third party service) and it does not error out due to time limits.

Precisely my point. Script actions are where the vast majority of scripting is being requested and developed. My clients (and others) are attempting [increasingly] to put distance between them and the calamities associated with Zapier. Ergo, it’s a constraint worthy of consideration in everything we develop. :winking_face:

If the time limit is per action, one action could timeout and break the whole automation (I assume other actions wouldn’t be executed), which could leave you in a state of “half-done-things” and break a lot of other things afterwards.

What do you mean regarding Zapier? I’ve started using it seriously only recently and would love some insight on this.

Well, no luck getting more automations for us. But the workaround mentioned is great for some use cases. (using a synced base to run external automations, like sending emails/messages)

image

Well, I guess you did hear about the big disaster with Zapier a week ago last Thursday when almost every Zap started to fail. Recovery took quite a while and any company heavily dependent upon zaps running in a timely fashion were essentially put out of business for a day or so. Sometimes interrupts of service are innocuous - that one was significant.

Wasn’t aware, didn’t even notice. :grinning_face_with_sweat:

I’ll look into it, though. Thanks!

Correct. If a script takes too much time, none of the following actions will be performed.

I might be quibbling about tiny things here. I suspect that the scripts that you develop are much more complex and time/resource intensive than those of many other scripts floating around. I’m mostly trying to point out that if one has 25 actions in an automation, the time limit does not apply to the total time of the entire automation.

By the way, the recent redesign of the automations screen has a lot of screen real estate. I wonder if that extra real estate is being prepared for something interesting.

I think I understood that, but ti be clear, there are two different time constraints in automation steps that use scripts, right?

  1. Aggregate CPU cycle consumed (5.0 seconds?)
  2. Aggregate script process (30 seconds?)

My understanding is that each scripting action can have up to 1 second of CPU time and up to 30 seconds of elapse time. This means that an automation with 25 scripting actions could have theoretical maximum of 25 seconds of CPU time and 12.5 minutes of elapse time.

I can no longer find documentation that states the 1 second of CPU time limit, so that limit may have been changed or removed. I think this page used to state the 1 second CPU time limit, but it no longer does. Testing an automation also no longer lists the CPU time, but only the run time (out of 30 seconds) and the memory used (out of 512 MB).

Thus, it may be that the only time based limit is 30 seconds elapse time per action.

I have created an automation where every other script was nothing but a delay between retries. The automation ran successfully taking a total elapse time of well over 30 seconds over the course of multiple actions. Now, I did not subject this automation to the extensive loads that your clients may need, so you finding may vary.


The limit of 30 seconds elapse time is very annoying when doing an API call that might require more than 30 seconds to respond. I haven’t figured out a way to make that work, but we already discussed that in another of your threads.