n8n FAILURE MODES — WHAT BREAKS AND WHY
═══════════════════════════════════════════════════════════════

  FAILURE MODE 1: SILENT ERRORS
  ├── What: A node returns an error response (e.g., 429 Rate Limited)
  ├── n8n behavior: Marks execution as "error" but continues
  ├── Result: Google Sheet gets empty rows, emails go out
  │   with {{undefined}} in the subject line
  ├── Detection: Only visible in n8n execution history
  └── Danger level: HIGH — looks like success, delivers garbage

  FAILURE MODE 2: CONNECTION TIMEOUTS
  ├── What: VPS network blip, external API down, PTCL drops
  ├── n8n behavior: Workflow hangs, then times out
  ├── Result: No data moves, no alert fires
  ├── Detection: Only noticed if you manually check
  └── Danger level: HIGH — especially in Pakistan's infrastructure

  FAILURE MODE 3: CREDENTIAL EXPIRATION
  ├── What: OAuth tokens for Google/LinkedIn/Gmail expire
  ├── n8n behavior: Every execution fails with 401 Unauthorized
  ├── Result: All workflows using that credential break silently
  ├── Detection: Sometimes 48+ hours before anyone notices
  └── Danger level: CRITICAL — affects ALL client workflows

═══════════════════════════════════════════════════════════════

THE 4-LAYER MONITORING ARCHITECTURE
═══════════════════════════════════════════════════════════════

  LAYER 1: ERROR WORKFLOW (Catches all failures)
  ├── n8n Settings → Error Workflow → "_error_handler"
  ├── Fires whenever ANY workflow in your instance fails
  ├── Sends alert via WhatsApp/Slack/Email within seconds
  └── Logs error to Google Sheet for monthly review

  LAYER 2: HEALTH CHECK PINGS (Is n8n alive?)
  ├── Separate workflow: "_health_check" runs every 10 minutes
  ├── Hits http://localhost:5678/healthz
  ├── If no response → alert fires
  └── External: UptimeRobot (free) pings your n8n URL

  LAYER 3: RETRY LOGIC (Handle transient failures)
  ├── HTTP Request nodes → Settings → Retry on Fail
  ├── 3 attempts, 5-second delay between each
  ├── Custom retry: IF node checks status code → loop back
  └── 80% of API failures resolve within 3 retries

  LAYER 4: DAILY SUMMARY REPORT (Overview without checking)
  ├── Scheduled workflow at 8 PM PKT daily
  ├── Counts executions per workflow (success/fail)
  ├── Sends formatted WhatsApp summary
  └── Flags any workflow with >5% failure rate

═══════════════════════════════════════════════════════════════

Node 1: Error Trigger
  → Receives: workflow name, error message, node name, execution ID

Node 2: Set Node (Format the alert)
  → Expression:
  Workflow: {{$json.workflow.name}}
  Error: {{$json.execution.error.message}}
  Node: {{$json.execution.error.node.name}}
  Time: {{new Date().toLocaleString('en-PK', {timeZone: 'Asia/Karachi'})}}
  Execution ID: {{$json.execution.id}}

Node 3: HTTP Request (WhatsApp Alert via WATI)
  → POST to WATI API with formatted error message
  → Sends to your personal WhatsApp immediately

Node 4: Google Sheets Append (Error Log)
  → Columns: Timestamp, Workflow, Node, Error Message, Execution ID
  → This becomes your error history database

RETRY CONFIGURATION FOR CRITICAL NODES
═══════════════════════════════════════════════════════════════

  BUILT-IN RETRY (Any HTTP Request node):
  ├── Node Settings → Retry on Fail → Enable
  ├── Number of tries: 3
  ├── Wait between tries: 5000ms (5 seconds)
  └── Works for: 429 (rate limit), 500 (server error), timeout

  CUSTOM RETRY (For advanced control):
  ├── HTTP Request → IF Node (check status code)
  │   ├── Status 200 → Continue workflow
  │   └── Status != 200 → Wait node (30s) → Loop back
  ├── Counter variable tracks attempts (max 3)
  ├── After 3 failures → Route to Dead Letter Queue
  └── DLQ = Google Sheet "RETRY_MANUAL" for human review

  EXPONENTIAL BACKOFF (For rate-limited APIs):
  ├── Attempt 1: wait 2 seconds
  ├── Attempt 2: wait 4 seconds
  ├── Attempt 3: wait 8 seconds
  └── Formula: {{ Math.pow(2, $json.attempt) * 1000 }} ms

═══════════════════════════════════════════════════════════════

Daily Report WhatsApp Message Format:

*n8n Daily Report — {{date}}*

Lead Gen Pipeline: 23 runs, 1 failure
Order Processing: 67 runs, 0 failures
Social Poster: 5 runs, 2 failures

*Action needed:* Social poster errors — check Twitter API credentials

Total executions: 95
Success rate: 96.8%

PAKISTAN INFRASTRUCTURE REALITY CHECK
═══════════════════════════════════════════════════════════════

  CHALLENGE 1: INTERNET INSTABILITY
  ├── PTCL and Stormfiber have frequent micro-outages
  ├── Impact: Webhooks from client sites timeout
  ├── Solution: VPS in Germany/Singapore (Contabo/Hetzner)
  │   so n8n stays online even when PK internet drops
  └── Add: webhook retry queue for failed incoming calls

  CHALLENGE 2: POWER OUTAGES
  ├── Load-shedding affects home-hosted setups
  ├── Impact: If you run n8n on local machine, it dies with power
  ├── Solution: ALWAYS use a VPS, never host locally
  └── Cost: PKR 1,960/month (Contabo $7) vs. PKR 0 risk

  CHALLENGE 3: API RATE LIMITS ON PK IPS
  ├── Some APIs rate-limit Pakistani IP ranges more aggressively
  ├── Impact: More 429 errors than US/EU users experience
  ├── Solution: VPS in EU/US region for API calls
  └── Bonus: Lower latency to US/EU APIs

  CHALLENGE 4: CLIENT TIMEZONE GAPS
  ├── Your PKT (UTC+5) vs. client's workday
  ├── Impact: Errors at 2 AM PKT are 6 PM US EST — client notices
  ├── Solution: Instant WhatsApp alerts + auto-retry
  └── Never let a client discover an error before you do

═══════════════════════════════════════════════════════════════