I’ve been thinking about how to tackle the problem of cron-triggered workflows filling up the execution logs. While it’s straightforward to clear the job history every n number of days, it tends to still be messy (you have to scroll through a ton of logs to see other items that executed).
My idea is to have an option that lets you set a specific node in the workflow as being the one that determines whether the execution is recorded or not. In other words, “record to execution log when this node completes.” As a fallback, if no node is set as the ‘execution finalizer’, then every run of the workflow would be recorded as normal (the default).
For example, say you have an email node chained to an if node that sends an email when a certain condition is met - the job should only get recorded to the executions log if the email node runs, but not if it doesn’t (in other words don’t record executions when the if node returns false).
I think it would be beneficial to add this because:
It would make the execution logs much more readable when workflows with cron triggers are used.
Any resources to support this?
Not that I know of
Are you willing to work on this?
I’m not an n8n developer but I’m willing to help with testing
I like the idea of having some more control over this kind of thing.
Would however not be a fast thing to implement I think, as there are a few aspects that need changing for this.
Still in doubt if I will cast a vote on this.
Have you looked at the n8n API?
You should be able to simply go through the executions regularly and delete them if the execution doesn’t list the node you want to check for.
It’s a bit of a work around, but if you only have a few of these types of workflows it should be fairly straightforward to fix. Or even make it more general with a workflow ID and the node to be checking for.
I might even create a workflow like this soon if I get around to it.
Yes it’s possible to ‘clean’ the executions history in a number of different ways.
However this doesn’t tell me which node executed.
So in this case, the workflow always shows even if the email never gets sent - which is OK, because that’s what you expect - you want it to show the workflow run . . . except when you don’t
I suppose another possible way around this would be to use the ‘Execute Workflow’ node to trigger a second workflow, and simply disable execution history on the parent workflow.
So what it comes down to is that having such a feature would simplify this task.
So my understanding is that in order to see the nodes in the executions history you have to enable that under the workflow settings, but there is warning there that it adds latency.
Rather than adding latency / risking increased server load by recording every node here’s what I opted for:
I separated the “Check” aka the cron trigger + if logic into its own workflow
Disabled recording “successful” executions on that workflow
Moved the email node into its own workflow, with successful executions enabled
If the result = true, start the second workflow
This way, it results in the behaviour that I want
I think I can use this for other similar workflows too! Have both a check and a trigger - it’s a bit more moving parts but it works well!
When getting the execution you can enable the details. In the details you see the nodes that executed. Below you see that the node called “TRUE” is logged and “FALSE” is not. This is what I meant by checking the nodes and its executions.
Awesome! That’s the beauty of N8N - there are so many different ways to get what you want. I’m sure this thread will come in handy for others who are looking to do the same.
Basically a way to enable or disable execution logging within the workflow. At the moment my hack for a workflow that gets triggered many times but only passes a specific conditional a handful of times is to disable logging successful executions and add a Stop And Error at the very end of the last node.