The All Executions workflow list is useful in theory however it can be quite difficult to use with hundreds or thousands of executions. In my assessment, it would benefit from the following:
- Date Range Filter
- Time Range Filter
- Search by Execution ID
- Sort by Execution Length (i.e., the longest executions will be at the top of the list)
- Filter by Execution Length (e.g., view all executions lasting between 30 seconds and 120 seconds)
In addition to the foregoing, it would be helpful if a custom reference could be stored with each execution. For example, an execution may have a particular customer ID or transaction ID. If this ID could be stored along with the execution, the user could quickly search for this ID to locate the execution record.
Although saving failed executions should keep the number of executions to a reasonable number, there are a few cases where this will not be desirable or effective:
- New Workflows - Saving successful executions is desirable to troubleshoot missing or malformed data, incorrect logic, and long execution time
- Downtime - An unexpected service outage affecting one or more nodes could result in a long list of failed executions
- Expired Credentials - Expired credentials could trigger calls to a particular node to fail which could result in a long list of failed executions
- API Change - A change to an API could result in a long list of failed executions
- n8n Upgrade Issue - A breaking change in a n8n upgrade could result in a long list of failed executions. For example, the Execute Workflow node appears to have mysteriously disappeared at some point.
These improvements will make the All Executions page useful and convenient beyond the first hundred records. It will assist users with troubleshooting and quickly responding to specific enquiries. For example, if a user identifies an error in an external record, the user can use the available information (date, time, custom reference) to find the workflow execution that created the record and find out what went wrong. Without this, the user may spend hours looking for the record or may decide instead to guess the problem.
Sorting and filtering by execution length can help a user to quickly identify inefficient or problematic workflows. Long running workflows will be immediately obvious however it would also be helpful to identify unexpectedly short executions since something is probably wrong with the input or the logic that prevents it from progressing to subsequent nodes.
The n8n API already allows retrieval of a workflow by its workflow ID. This should be the easiest part of this request to implement. Users could, while waiting for the other improvements, store the workflow ID in their records to assist them with locating the correct workflow.