Check Node Execution Times to Find Bottlenecks

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
```text
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:

```text title="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.
```text
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](../error-handling-and-reliability/01-always-set-an-error-workflow-on-every-production-workflow.md) | [Break Large Workflows into Sub-Workflows](../workflow-architecture/01-break-large-workflows-into-sub-workflows.md)