Issue 8 • February 3, 2026

Why Loops Explode

Loops need an exit condition. When the condition fails, the loop runs forever. Here are a few common ways it happens:

1. Missing or Broken Termination Condition

Loop while items.length > 0
  Process item
  // Forgot to remove item from array

The array never shrinks. The loop never ends.

2. Data Creates More Data

For each customer:
  Get their orders
  For each order:
    Get line items
    // Customer has 1000 orders with 50 items each
    // Expected: 500 iterations
    // Actual: 500 x 1000 x 50 = 25,000,000 iterations

Your test data had 2 orders per customer. Production has customers with thousands.

3. Circular References

Process record A
  A references B → Process B
  B references C → Process C
  C references A → Process A (again)
  // Infinite cycle

Data has relationships you didn't anticipate. The loop follows them forever.

4. Webhook Triggers Itself

Webhook receives update
  → Updates record in CRM
  → CRM fires webhook for update
  → Workflow receives webhook
  → Updates record in CRM
  → ... forever

The most dangerous loop: your workflow triggers itself.

Safeguard 1: Maximum Iteration Limits

Every loop should have a hard limit, even if you don't think you need one.

Implementation:

Set iteration_count = 0
Set MAX_ITERATIONS = 1000

Loop:
  iteration_count += 1

  If iteration_count > MAX_ITERATIONS:
    Log error: "Loop exceeded maximum iterations"
    Alert: "Possible runaway loop in [Workflow]"
    Exit loop

  // Normal processing

Choosing your limit:

• Know your expected maximum (500 customers? 10,000 orders?)
• Set limit at 2-3x expected maximum
• If limit is hit, something is wrong, don't just increase the limit

n8n Pattern:

Use a counter variable that increments each iteration. Add an IF node that checks if counter exceeds limit. If yes, break out of the loop and send an alert.

Safeguard 2: Timeout Limits

Sometimes iteration count isn't enough. A single iteration might hang forever.

Implementation:

Set workflow-level and node-level timeouts:

• Workflow timeout: Maximum total execution time (e.g., 30 minutes)
• Node timeout: Maximum time for a single operation (e.g., 60 seconds)

n8n Configuration:

Workflow Settings → Execution Timeout → 1800000 (30 minutes)

Individual HTTP nodes → Settings → Timeout → 60000 (60 seconds)

What happens when timeout hits:

• Workflow fails
• You get notified
• Partial data may be processed (this is why you need idempotency)

Safeguard 3: Processed Record Tracking

Prevent processing the same record twice in the same execution.

Implementation:

Set processed_ids = []

For each record:
  If record.id in processed_ids:
    Log: "Skipping already processed record"
    Continue to next

  Process record
  Add record.id to processed_ids

Why this helps:

• Catches circular references (A → B → A)
• Prevents duplicate processing if data appears multiple times
• Creates audit trail of what was actually processed

n8n Pattern:

Use a Set node to maintain an array of processed IDs. Before processing, check if the current ID exists in the array. If yes, skip. If no, add it and continue.

Safeguard 4: Self-Trigger Prevention

The most dangerous loop is when your workflow triggers itself.

How it happens:

1. Webhook triggers on "record updated"
2. Workflow updates the record
3. Update triggers the webhook
4. Workflow runs again
5. Infinite loop

Prevention strategies:

Strategy 1: Add a "processed" flag

If record.automation_processed == true:
  Exit (already handled by automation)

Process record
Set record.automation_processed = true

Strategy 2: Check the update source

If webhook.source == "automation":
  Exit (we triggered this ourselves)

Process record
// When updating, set source = "automation"

Strategy 3: Debounce with timestamps

If record.last_updated < 5 seconds ago:
  Exit (too recent, probably our own update)

Process record
Set record.last_updated = now

Strategy 4: Use separate trigger fields

Instead of triggering on "any update," trigger only on specific field changes that your workflow doesn't modify.

Safeguard 5: Batch Processing with Checkpoints

Don't process 10,000 records in one execution. Process in batches with checkpoints.

Implementation:

Get all records where status = "pending"
Take first 100 records (batch)

For each record in batch:
  Process record
  Set status = "processed"

If more pending records exist:
  Trigger self to process next batch
  // Or schedule next batch in 1 minute

Benefits:

• Memory stays bounded (only 100 records in memory)
• If something fails, you know exactly where you stopped
• Can be paused/resumed between batches
• Other workflows can run between batches

n8n Pattern:

Use "Split In Batches" node with batch size of 100. After processing each batch, the workflow pauses and picks up the next batch. Add a checkpoint log after each batch completes.

Safeguard 6: Resource Monitoring

Know when your loop is consuming too many resources.

What to monitor:

• Execution time (is this taking longer than expected?)
• Memory usage (is it growing unbounded?)
• API calls (are you hitting rate limits?)
• Output size (are you generating too much data?)

Implementation:

Add periodic checkpoints in your loop:

Every 100 iterations:
  Log: "Processed 100-200, memory: X, time elapsed: Y"

  If memory > threshold:
    Alert and pause

  If time > expected:
    Alert (but continue if resources are okay)

Testing for Loop Safety

Before deploying any workflow with loops:

Test 1: Empty data

• What happens with 0 records?
• Does the loop handle empty arrays gracefully?

Test 2: Single record

• Does it process one record correctly?
• Does it exit properly after one iteration?

Test 3: Expected volume

• Test with realistic production volume
• Monitor time and resource usage

Test 4: 10x expected volume

• What happens with 10x normal data?
• Does it hit your safeguards appropriately?

Test 5: Circular data

• If your data can have relationships, test circular references
• A → B → A should not cause infinite loop