Check Node Execution Times to Find Bottlenecks

n8n's execution detail view shows how long every node took to run. To find why a workflow is slow, open a completed execution and read the per-node timings; the bottleneck is usually one node -- a high-latency API call, a Code node processing thousands of items, or an unindexed database query. Fix that node with batching, concurrency, or a bulk pre-fetch.

How do you find the bottleneck node in n8n?

The execution detail view shows how long each node took to execute. When a workflow is slower than expected, open a completed execution and look at the timing for each node. The bottleneck is usually a single node -- an API call with high latency, a Code node processing thousands of items, or a database query missing an index.

Real-world example: Your workflow takes 45 seconds to process a batch of customer records. You need to find which node is the bottleneck.

Node                          Items    Time
--------------------------------------------
Webhook Trigger               1        2ms
Airtable - Get Records        1        850ms
Code - Transform Records      248      120ms
Loop Over Items               248      --
  HTTP Request - Enrich       1/each   38.2s  <-- BOTTLENECK
  Set - Format Output         1/each   15ms
Merge Results                 248      45ms
Google Sheets - Write         248      1.8s
Slack - Send Summary          1        340ms
--------------------------------------------
Total                                  ~42s

How do you fix the slowest node?

The HTTP Request inside the loop takes 38 seconds because it makes 248 sequential API calls (approximately 154 ms each). The fix depends on the API:

Optimization Options

Option A: Use batching if the API supports it.
  Instead of 248 individual calls, send batches of 50.
  Result: 5 API calls instead of 248 -> ~1 second.

Option B: Use the "Batch Size" setting on the HTTP Request node.
  Set "Batch Size" to 10 for 10 concurrent requests.
  Result: ~25 batches of 10 -> ~4 seconds.

Option C: Pre-fetch all enrichment data in a single query.
  Replace the loop with a single bulk API call before
  processing, then use the Merge node to join data.
  Result: 1 API call -> ~200ms.

Why check execution times before optimizing?

Checking execution times first prevents you from optimizing the wrong node. The slowest node is not always where you expect it to be.

Related: Always Set an Error Workflow on Every Production Workflow · Break Large Workflows into Sub-Workflows