The Time Saved node is easy to wire up and easy to wire up wrong. I’ve been poking at it on a test instance for a couple of days, mostly to find where the number comes apart when somebody outside the team starts asking about it. Two things stood out. Both are fixable in n8n as it stands.
Per-item mode is linear. People aren’t.
Per-item multiplies your minutes by the input item count. That assumes the 30th record costs a person what the 1st did, and it doesn’t, because people batch. You open the system once, load the context once, wrap up once. Only the middle part repeats.
What holds up is fixed plus marginal:
time saved per run = F + (M × items)
You can express that in n8n today, because every Time Saved node that executes gets summed. Two nodes on the success path:
- one on “once per execution”, minutes = the overhead a person pays regardless of how many records came through
- one on “per item”, minutes = the genuine incremental cost per record, which is usually a lot smaller than your first guess
Say a job takes about 6 minutes of setup plus 1.5 per record. A 30-record run is 6 + 45 = 51 minutes. A single per-item node at a blended 7.5 books 225. That’s 4.4×, and it’s the kind of gap someone finds in about ninety seconds.
Sub-workflows don’t count at all.
This one isn’t a mistake you make, it’s just not written anywhere you’d think to look. From the docs: “Time saved tracking currently only works on parent workflows. Time saved from subworkflows isn’t currently supported, with plans to support this in a future release.”
So if you took the usual advice and split your work into sub-workflows, Insights is quietly under-counting you.
You can work around it without any webhook scaffolding by having the sub-workflows report themselves. Inside a sub-workflow, {{ $execution.id }} is that sub-execution’s own id. I checked rather than assumed, since the docs don’t say either way — a parent run came back 102 and its child 103, and {{ $workflow.id }} resolves to the child’s workflow too, so the whole context is child-scoped. Put a “record this run” step at the end of each sub-workflow, an HTTP call or a DB insert carrying the execution id and an item count, and you’ve counted every sub-execution. The execution id doubles as a dedupe key, so retries don’t double-count.
Watch out for loops. Every iteration of one execution shares the same execution id, so a recording step inside a loop collapses to a single row once you dedupe. Aggregate first, record once, pass the item count.
Why go to the trouble of the smaller number
Because the smaller number is the one that survives someone poking at it. A figure that’s 4× too high doesn’t get negotiated down to something reasonable. It gets the whole report thrown out, and it costs you the next one too.
Disclosure: I build LumaTrack, a tool in this space, so weigh my bias accordingly. Everything above is n8n on its own, no tool required.