Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

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 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