I have a group of macros that I run every morning at 6am.
I have this main macro that gets triggered at that time and that macro has multiple Execute Macro actions that trigger those other macros (I like to keep things separated). I have most of those actions to execute async, but some of them not, because I want to make sure everything is done before moving on.
If I decide to remove them from the main macro and add the trigger to each macro to 6am, is there any risk of them clogging the engine, or something?
It depends. It really depends on the macro and what it’s doing, I don’t know of any hard limits in KM, but I know if you have 15 macros that all fire at the same time they will all run. If I have resource heavy jobs / macros on a schedule, then I do space them out a bit and I find that doing so will sometimes help what might end up creating a resource bottleneck.
My advice, test it, pull up activity monitor and see how your mac is doing, or run ‘top’ in the terminal
But, from what you wrote, this won't be a problem because you are already running many of these macros at the same time (async executes from your main).
If you are simply changing many of the macros to being triggered by time rather than async triggered by your main, there's not going to that much of a change to the amount of "work" the Engine is doing at any particular time. If you're worried, stagger them -- 6:01, 6:02,... -- which you might want to do anyway so you aren't asking your Mac to do too many things at once.
What's the reason for the change? It would seem to me that a single "master" macro that fires off all your others in the order that you want would be simpler to manage and maintain than a bunch of separate macros all triggered at the same time.
Most "start the day" macros I've seen place way more stress on the computer as a whole -- launching apps, mounting shares, syncing email, etc -- than on the KM Engine in particular.
Today I changed some of them to be like that: 6:00, 6:01, etc.
I had a single macro running most of them with async, but then inside I had some that I want to run without any other macros running. The issue lately was that some macros would stop responding and the main macro would fail, so some of the last macros wouldn't run. I tend to keep track of failing macros and fix them every week or so, but sometimes some still fail randomly.
Some of these macros were local backups I wanted to create for particular folders, but now that I'm using Back Blaze that runs every hour, those daily macros make absolutely no sense (apart from my local backup as well). I was able to reduce that list of macros to maybe half.
I need to take a look at that again, and maybe I can group all the async macros into a single macro.
I was aware of the 50 macros limit, and I never even get close to that. I don't think I've ever had even 10 running at the same time, let alone 50...
Maybe that's why mine was failing. I'm always one step ahead (or behind...).
Yes, I tend to have scheduled macros trigger at different times to avoid conflicts. These ones are just macros that I run at 6 am, which is when I'm still asleep. When I wake up early and 6 am comes, the main macro shows me a warning to avoid messing with the computer, just because some of them depend on some "Found image" actions, or some scripts that require the screen to be reliably "static", if that makes sense?
But today I was able to slash that list to maybe half so I will find a new approach. As long as I'm below 14 macros at the same time...
It's not 50 macros, it's concurrently executing instances. And even that's not the full story -- if you have a recursive macro then each level of recursion accounts for 2 executing instances, each level of "nesting" (the "Group" Action, the "If... Then... Else" Action, and so on) also counts as an executing instance (I think -- I'm never sure where the line is drawn).
So yes, I'm sure you've often hit 10 -- though maybe not 50!
If you do want to see what happens when you break the limit (check the Engine log) have a play with my recursive String Reversal demo.
So, you're saying that if I have a For Each, inside another For Each, for example, that would count as 2 executing instances? And groups too? I use groups a lot. Should that be avoided?
Try it and find out? If you haven't changed the default limit, does a macro with 26 nested "For Each"s execute or crash?
Similarly with Groups -- and if you are nesting "Group" Actions to that level, to what purpose? There comes point where over-nesting will make your macro less manageable, not more organised. Also, a "Group" Action is an Action and, like all Actions, has an execution time -- each "Group" adds ~1ms to your macro's execution time (and adds to your plists size, infinitesimally increases the Engine's re-load time, etc).
But it really isn't worth worrying about. Just be aware that there is a limit and that if you're investigating a problem macro and see
2025-12-06 18:49:42 More than 50 simultaneous macros - aborting everything
2
...in the Engine log (with your own time stamp and limit number, obvs!) then you've hit it and might want to investigate why.
(And yes, that error was generated by running a macro with >50 nested "Group" Actions...)