Workflow_statistics table: what exactly does rootCount mean, and does it relate to billing?

Questions
1

workflow_statistics table: what exactly does rootCount mean, and does it relate to billing?

While digging into execution counts for one of our workflows, I ran a query directly against the database:

SELECT * FROM workflow_statistics ORDER BY count DESC;

For one workflow I got something like this:

count rootCount name
21,774,704 17,306,420 production_success

So count and rootCount differ by roughly 4.47M. The workflow itself contains no Execute Sub-workflow / Call n8n Workflow Tool nodes, so at first I assumed the difference must come from other workflows calling this one as a sub-workflow or as an AI Agent tool.

My questions for the community (and maybe n8n staff):

  1. What is the exact, documented definition of rootCount vs count in the workflow_statistics table? Is rootCount really “this workflow was the top-level entry point of the execution chain,” while count includes every run regardless of whether it was invoked by another workflow (Execute Workflow node, AI Agent tool-workflow, error workflow, etc.)?
  2. Is there an official source (docs, source code comment, changelog) that defines this precisely? I’ve only been able to infer it from the column name and from the Insights docs, which state that Insights only counts production executions from the parent workflow, not sub-workflow or error-workflow runs. That’s a related but distinct feature from this raw table.
  3. Billing question: does rootCount correspond to what actually counts against your execution quota/plan? Several third-party pricing write-ups state the opposite — that sub-workflow executions (triggered via the Execute Workflow node) are billed as separate, additional executions, not excluded. If that’s accurate, rootCount would understate billed usage, not represent it.
  4. If your workflow itself has no sub-workflow nodes but count and rootCount still diverge significantly, where else should we look? So far I’ve checked: nodes::text LIKE '%<workflowId>%' across workflow_entity (came back empty)

Would really appreciate it if someone from the n8n team, or anyone who has dug into this before, could confirm the exact semantics of rootCount and clarify whether it lines up with billed/quota-counted executions or not. Happy to share more of my query results if that helps narrow it down.

Thanks in advance!

2

@abc

These are my best guess

  • count: This is the total number of executions of the workflow, regardless of the trigger source. Every time the workflow runs to completion (success, error, or crashed), this counter is incremented.
  • rootCount: This represents the number of times the workflow acted as the top-level entry point (the “root”) of an execution chain.

While this is not explicitly detailed in the end-user documentation, the logic is defined in the n8n core source code:

  • WorkflowStatisticsService: This service handles the logic for updating these statistics upon workflow completion.
  • Integration Tests​: The file workflow-statistics.service.integration.test.ts explicitly verifies that modes like trigger, webhook, and cli increment both counters, while modes like integrated and internal (sub-workflows) only increment count.

Yes, rootCount is the primary metric for billing and execution quotas.

In n8n’s licensing and metrics system (specifically within the LicenseMetricsService), the system tracks productionRootExecutions. The goal is to bill based on the “parent” execution that started the process, rather than every single sub-workflow call.

This is further confirmed by recent core changes (e.g., GitHub issue #32544), where n8n explicitly ensured that Error Workflows (triggered by the Error Trigger node) do not count toward billable limits by forcing their rootCount to 0, even though their count still increases.

If your workflow contains no “Execute Sub-workflow” nodes but count is significantly higher than rootCount, it means your workflow is being called as a sub-workflow by other workflows.

The count in the workflow_statistics table for Workflow B increases whenever Workflow A calls it. Since you’ve already checked for workflowId references in the workflow_entity nodes and found nothing, consider these possibilities:

  • AI Agents: If this workflow is registered as a Tool for an AI Agent, the agent invokes it as a sub-workflow.
  • Dynamic Workflow IDs: Other workflows might be calling this workflow using an expression to determine the ID, rather than a hardcoded selection, which is why a simple text search for the ID in the database might have failed.

Does that help?