My goal:
I want to receive a notification if the frontmost app has zero windows or all its windows are minimized.
I have been trying with the focused window trigger.
It works perfect to detect title/frame changes if there are windows.
But when windows are zero, sometimes it detects the lack of windows but the most of the times it's not detecting it.
Do you have some ideas how could I achieve this?
I recommend that you examine the WINDOWCOUNT() function, which can probably return zero, and see if you can combine it with your code to detect that condition.
If that doesn't work, I suggest you consider a polling macro which checks every quarter of a second to return the count of the number of windows of the futon app. If you combine that with a check of the name of the front app, you can detect whether a window opens or closes. Some people object to a macro that "polls", but it's very efficient and gets the job done.
In what situations are you experiencing the macro not triggering as desired? When the frontmost app number of windows drops to zero (or is being minimized)? Or when entering an app with no window, (or where all windows are closed or minimized?).
But in what apps have you experiencing the Window trigger not being triggered? Using "The focused window title changes" trigger, the few apps I've tested here now trigger when closing the last window, also upon entering an app where all windows are closed.
If it is upon entering an app you want the notification to be given, then you might get better result from the Application trigger, with settings 'Any Application: Activates'.
Minimized windows are trickier to detect though. Minimized windows are still returning the name of the 'topmost' window (in the list of minimized windows, disclosed when right-clicking the app's dock icon) even when all windows are minimized. Minimized windows are also counted towards the total number of windows returned by the WINDOWCOUNT() function. It should be possible to create an Apple Script that can detect a windows minimized state, something that can be turned into a condition. But a trigger from the act of minimizing is something I do not believe is possible, and polling would then be your only option.
Under what circumstances.
That'll be your clue, here. Triggers are events, including the "another second has passed" event before anyone mentions Periodic or Cron 
, so what do you do when it doesn't fire and, by extension, what event(s) are you missing from your trigger list?
Depending upon the applications involved here, it might be useful to test whether the menu item "Close Window" is available, but I doubt that that would have any advantage over @Airy’s suggestion of using WINDOWCOUNT(), for most situations.
Oh, but it has!
"Close Window" Menu Item is also not enabled when all windows are minimized, whereas WINDOWCOUNT() would return the number of minimized windows even when all are minimized.
Some apps have that Menu Item named simply as "Close" though, so for use with different apps, it could be best to check if Menu Item "Close Window" OR "Close" is enabled.
From some testing here now, an app like TextEdit does not have its Menu Item "Close" enabled when the "Open" (New Document) window is being displayed, even though it counts as a window according to the WINDOWCOUNT() — so one might consider checking if (Menu Item "Close Window" OR "Close" is enabled) AND WINDOWCOUNT() > 0
For whatever reason, I cannot get the "A menu item with name matching" working reliably with the alternation Close Window|Close here now
But this convoluted variant seems to work reliably here on my system:
Zero window notification.kmmacros (7.3 KB)
KM v11.0.4
I am glad to learn that this is one such situation! 
I never think in terms of minimised windows, because I try to avoid windows becoming minimised (and indeed my main use for BetterTouchTool is remapping ⌘-M).
Thanks all for all your support. You're awesome! 
WINDOWCOUNT() counts the minimized windows, so I prefer to not use it
Checking if "close window|close|etc" menu item is enabled is tricky, as I have applications like Ableton Live where this menu item is disabled when there is only the main window. Perhaps I could configure a case-per-case condition depending of every app, but I would prefer to find a global solution.
Situations where macro is not triggering as expected:
The main problem is when I close the last opened window. In other words, when the qty of windows changes from 1 to 0.
This problem happens only in some apps. As example, I'm not experiencing this in Finder.
But with other apps, like TextEdit or Pages, the trigger is not detecting when I close the last document/window.
You can test it using cmd+N and cmd+W. When creating new documents, everything works as expected, but when you close the last document of TextEdit/Pages, the macro is not triggered.
Situations where everything works flawlessly:
How do I configure a polling macro like the one you suggest?
I guess it is using cron or periodic trigger, but maybe it is better using an infinite loop with a pause in the actions.
What should be the recommended way of doing a polling macro in KM?
I am considering that a good solution would be to use the shortcut "cmd+W" as a trigger for the "problematic" apps (like TextEdit or Pages).
So everytime I press cmd+W to close a window in a "problematic" app, KM would trigger the actions to check the qty of windows.
But I see that the trigger cmd+W in KM overrides the shortcut of the app, so the app is not closing the windows when I press cmd+W.
How do I trigger the actions after pressing cmd+W without overriding the front app shortcut?
No. It does not use cron or periodic trigger. It uses an infinite loop with a "Pause 0.25 seconds" action inside it. Since there is a Pause action inside the loop, it will not use a lot of resources.
Even though it's an infinite loop, you still have to start it somehow. And indeed, I prefer a periodic trigger, but then the first action of the macro needs to be a semaphore that prevents multiple copies of the macro from running at the same time.
I do this sort of thing all the time in my macros, when I need to poll often.
Either you need CMD-W to trigger the macro, or trigger the app's menu item. You can't have it both ways. You said "without overriding" but that's having it both ways. You have to pick one. Which one do you want?
EDIT: I see below that you didn't mean what I thought you meant. When you said "without overriding" I think you meant with regard to KM using the shortcut, not the user's ability to use the shortcut. Sure, that should work.
Alternatively, if that does eventually fail or result in a conflict, you could pop in a Select or Show Menu Item action at the top of the macro instead.
When troubleshooting and running into problems, it's worth taking a close look at your assumptions. For example:
Perhaps because you never close the last window in Finder -- remember, the Desktop is a window! There's always a window to compare the properties of the window just closed against.
That's not the issue here, though. Something is, and I'm wondering if it's something in your setup, because this:
...works fine for me when closing the last window of both TextEdit and Pages.
You really need to post the actual macro that is failing to trigger, not screenshots of it.
What are you actually trying to do on the closure of the last window? I'll admit I'm not a fan of that approach in general because I'm then often stuck wanting to close the last window of an app without triggering the macro, so would rather do what you're heading towards -- set a hot key trigger for a macro that closes the window and, if that was the last, do a thing -- so I can still use the window button or menu item when I want to close it without the macro running.
This is the macro I have been using (it's the screenshot of the 1st post). This macro is the v1:
Detect Window Changes v1.kmmacros (1.8 KB)
This is the same macro, but I have removed 3 triggers to leave the same single trigger of your screenshot ("The focused window title changes"). This macro is the v2:
Detect Window Changes v2.kmmacros (1.5 KB)
I have recorded this video enabling only the macro v2, after quiting all automation apps. Only Keyboard Maestro Engine is running.
All the windows of the video are opened or closed pressing CMD+W and CMD+N in Finder, TextEdit and Pages.
You can see that sometimes KM is not detecting when Windows=0 and Windows=1.
In the other hand KM always detects when Windows>1.
Can you replicate it doing more or less what I am doing in the video?
//edit: the window title "sense nom" you see in the video means "without name" in catalan. It's the name that the app gives to the new documents that are not saved.
Sorry, I don't understand this sentence.
How KM could run multiple copies of the macro if the loop is only in one macro?
I was thinking of trigger the infinite loop with the "At Engine Launch" trigger.
It would be better to use the periodic trigger for some reason?
KM can run dozens of copies of the same macro at the same time. All you have to do is trigger the same macro additional times before it is finished running. For example, if a macro takes 10 seconds to run, and the macro is triggered with the hotkey "F1", and you accidentally press F1 twice in a row, you will get two copies running at the same time. It's that easy. Do you understand now how two copies of the same macro could be running at the same time? It has nothing to do with whether the macro loops, rather it has to do with how many times the macro is triggered.
This is why I recommend a semaphore action at the top of a macro that starts an infinite loop, so that you don't get two copies running at the same time. Do you agree?
Yes, I believe it is better to use the periodic trigger, because that way if someone presses the "cancel all macros" hotkey, the macro will restart after a short while. Besides, the macro might not work "at engine launch" if the necessary conditions, like a running app, aren't yet running.
Well noted and fully agree. Thanks a lot for your explanations!
Also clear why it's better to use the periodic trigger.
You'll hate this -- but those two macros work 100% of the time for me...
While it looks like your macros aren't triggering -- the KM menu bar icon doesn't turn -- you should check properly. Watch the incoming entries in Engine.log -- an easy way to do that is to run the following in a Terminal window for a "live tail" of the log file:
tail -f ~/Library/Logs/Keyboard\ Maestro/Engine.log
...and when the trigger fires you'll see a line added like
2025-08-06 09:50:53 Execute macro “Detect Window Changes v2” from trigger The Focused Window Title Changes
When you're done watching, activate the Terminal window and hit ⌃C to stop.
If you can see it isn't firing -- on to normal troubleshooting. What are your macOS, KM, TextEdit and Pages versions? Does anything need updating (I'm assuming you aren't running betas...)? Does this happen in a "clean" account on that Mac? Have you another Mac you can try on? Can you change your language settings and try in UK English? Booting -- and logging in -- in Safe Mode (I think KM will still work, but you'll have to launch the Engine manually)?
At its heart the "Focused window title changes" just compares what the window title was with what it is now. It won't, for example, fire if you switch between two apps whose frontmost windows are both "Untitled.txt" or two apps with no open windows (since the frontmost window title for each will be an empty string). So if it isn't working then either KM isn't receiving the event or KM/the OS thinks the title is the same as previously for some reason...
It may, of course, be that I'm the odd one out and this is failing for everyone else Hopefully others will try those macros and report in.
Absolutely no, that are good news!
Following your suggestions:
Sorry, I don't know what a clean account means
Yes, my girlfriend has a Macbook Air M1with Sonoma.
I have downloaded KM in trial mode, installed it, removed all macros, create just one macro with the trigger "The focused window title changes" and it works perfectly 100% of the time.
So now the question is what's going on in my Macbook Pro M1 Max…
I assume that if the macro is not working in safe mode is becasue the cause of the problem is the configuration of my mac, so the casue can't be any other application. Do you think this statement is correct?
I have been checking my System Settings compared to the System Settings of the Macbook Air. I have tried to change several things but the issue persists.
Another cause could be that I'm running Sequoia.
I don't know what else I can do… Any ideas?