Macro runtime cap and timeout


I’ve encountered a couple of pain points when adding Distill into my workflow. I was hoping I could get some clarification, advice & submit a feature request.

Firstly some background information on my use case & Distill setup. I’m exclusively using the Windows Desktop App to monitor a large (900+) dynamic product wishlist. Accuracy, consistency & speed are vital for my application. Unfortunately, the site ( doesn’t allow the full wishlist to be loaded via the URL. I therefore use a Macro to click the “Load More” button which makes x8 more products visible, not ideal… This leads me to my first observation/question.

Do Macros have a hard runtime cap of 60 seconds to complete? This has been my experience to date. I seem to have reached a limit regarding the number of steps my macro can complete without experiencing major consistency errors. As such I’m only able to monitor 1/3 of the wishlist actively.

This leads me to my feature request, the addition of a looping function within macros. Currently, I’m having to manually input each click of the “Show More” button into my macro. This process is time-consuming and cumbersome. With a loop feature, I could create a macro scenario that automatically expands or contracts as needed, without requiring manual adjustments for each iteration.

If anyone has any suggestions to speed up or increase the time a macro has to run it would be greatly appreciated.

Many thanks in advance :slight_smile:

Welcome to the community forum and thanks for sharing your use case.

You should be able to increase timeout time for local monitors. Check Changing Timeout Length - #3 by raksha out.

It is in out roadmap and should tentatively be available by Q2 this year. :slight_smile:


Glad to see looping macros in the latest release :grin: reduced 105 steps into 1 :sweat_smile:


I haven’t been able to get While Loops to work. It clicks the “show more” button once & then completes. It’s almost like it evaluates the page too quickly but I don’t know for sure.


it appears that the CSS selector .kJukVH becomes temporarily unavailable when more items are loading, leading to an unintended early exit from the while loop due to the element_exists condition.

A more reliable approach would be to use a stable selector to identify the button, such as .sc-q3003p-5 > button. Additionally, integrating a wait_for_duration step will allow the webpage sufficient time to load more content, preventing rapid, successive button clicks. This should help maintain smoother interaction with the website.

Here is a screenshot of what worked for me.

Thanks, @noelzubinvictor for taking the time to give my situation a once-over. I can confirm that your while looping setup works with the updated element selector :grin:

As my wishlist is very extensive the delay steps mount up, speed is a vital component so this isn’t ideal. Could I therefore make a niche feature request?

Is it possible to specify that a certain monitor can only run from a set device? I’m thinking of splitting my large wishlist across multiple accounts. By adding an extra account (or two) it’ll speed up my monitor turnover & add redundancy. Much like widening a road!

I can then use one while looping macro across multiple devices logged into separate accounts :+1:

Hello @kappabaruh ! It looks like you’re trying to set up multiple monitors to run locally but on different devices. If you have another device, such as a separate browser, you can log in using the same account to add that device. And then, you can assign each monitor to the specific device you want it to run with.

Additionally, if you’re running into issues with responsiveness or timing in your setup, you might want to reduce the wait time in your while loop. You can set the duration to even lower fractional values like 0.5(500 milliseconds). This could help with quicker processing of clicks and other actions.

Screenshot 2024-05-10 at 9.49.12 PM

Let me know if you need more detailed guidance on any of these steps!

Thanks for the suggestions. I’ll try adding the second device & reducing the wait time. All in the pursuit of speed & consistency! :wink:

I know I’m pushing elements beyond the expected norm… like Timeout.


:crossed_fingers: Multiple devices running a single local monitor leveraging a looping macro can achieve this. I’m very hopeful!