Skip to main content
Question

What limits exist for how long a zap can take to complete?

  • 7 February 2022
  • 1 reply
  • 1338 views

I saw this thread:

And there is a somewhat alarming statement:

Your entire function only gets ~30 seconds to run.  There’s no way to control for extending that. 


I am working on a zap that needs to process a large list of elements. The zap would be triggered by a single event, which would then call an action to fetch a list, and then iterate over that list, and every page in that list. The size of the list could exceed 10,000 records. It is very likely that iterating over that list would take longer than 30 seconds. 

Something though doesn’t feel right to me about the above statement about 30 seconds. If I use delays and other mechanics, I could artificially force my zap to take longer than 30 seconds, forcing a failure every single time. 

@Zane can you clarify your statement about how long Zaps are allowed to run? And whether my use case above is achievable with the platform today?

This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

1 reply

Z
Userlevel 7
Badge +9

This is correct. The steps provided by your integration get about 30 seconds to complete all requests and processing. 

https://platform.zapier.com/docs/constraints

Zaps are built around workflows with fairly fine grained, single entity events and messages, rather than large batch or ETL processing.

You’re right to strongly consider the runtime profile of your transaction and make sure it reliably, comfortably fits within the processing window.

If you could share some more about your use case I’ll bet we could reorganize that transaction in a way that fits with the way users define and use Zaps. What’s a typical problem a user would be building a Zap to solve? What app and event would they use as a trigger?  If your action returned thousands of records, what would the user want to do with those, in their Zap, as a result?

For instance, what do the 10,000 items represent? Would your users want to perform an action on each of those items? Might a user want to create a trigger on those new items as they are created or updated rather than processing them in a batch?

You mention an action returning bulk data. Create actions are generally used to mutate data, creating or updating a resource. Search actions are expected to return a single unambiguous result. Triggers are the elements expected to yield large sets of objects, and then each of those objects is handed by a separate Zap execution.

Not uncommon exceptions to this include “line items” in orders where child objects must be handled together with the parent. And maybe your use case is similar. Also note any action would have to have been written by the app’s developer to expect a line item array, and they’d also have to be able to completely consume and handle that set of line items, within 30 seconds. 

You might also have a look at Transfer, which allows a user to retrieve data in bulk (from a specially implemented trigger) and process each returned object through a Zap workflow.

 

https://zapier.com/transfer

https://platform.zapier.com/docs/transfer

Terms & Conditions