Módulo 6: Manejo de Errores

Error Workflow y Error Trigger

Descripción de la cápsula

En G1-M06-06 viste Error Workflow básico — el workflow que se dispara cuando otro falla. Esta cápsula lo profundiza: cómo diseñar Error Workflows que realmente sirven, qué información capturar, patterns de notification, y consideraciones de mantenibilidad cuando tienes 10+ workflows productivos.

Lo que vas a aprender

✅ Diseñar Error Workflow efectivo
✅ Capturar información relevante del error
✅ Notificar por canal correcto según severidad
✅ Manejar Error Workflow para múltiples workflows productivos

Recap: Error Trigger

Error Trigger es un nodo trigger especial. Workflow con Error Trigger es callable como Error Workflow desde otros workflows.

Configuración del workflow padre:

Settings → Error Workflow → [elegir el workflow con Error Trigger]

Cuando el padre falla, se dispara el Error Workflow con datos sobre el fallo.

Datos disponibles en Error Trigger

El Error Trigger recibe un payload con info del workflow que falló:

{
  "execution": {
    "id": "abc123",
    "url": "https://...",
    "lastNodeExecuted": "HTTP Request",
    "error": {
      "message": "...",
      "name": "..."
    },
    "startedAt": "..."
  },
  "workflow": {
    "id": "...",
    "name": "..."
  }
}

Los nombres exactos pueden variar entre versiones de n8n.

Error Workflow básico

[Error Trigger]
   │
[Slack: notificar]
  Mensaje:
  🚨 Workflow falló: {{ $json.workflow.name }}
  Nodo: {{ $json.execution.lastNodeExecuted }}
  Error: {{ $json.execution.error.message }}
  Link: {{ $json.execution.url }}

Cualquier workflow con este asignado como Error Workflow, te avisa cuando falla.

Error Workflow profesional

Más sofisticado:

[Error Trigger]
   │
[Set: enrichecer con context]
  - severity: según workflow_name (prod-critical vs experimental)
  - readable_timestamp
  - direct_execution_link
   │
[Switch: severity]
├─→ "critical" → Slack #alerts-critical + SMS + PagerDuty
├─→ "high" → Slack #alerts
├─→ "medium" → Slack #alerts (silent — sin notification)
└─→ "low" → Solo log en Sheet
   │
[Sheet: log all errors]
  Para análisis posterior y métricas

Beneficios:

Severidad apropiada por workflow
Multi-canal según importancia
Historial agregado de errores

Detectar severidad

Cómo el Error Workflow sabe la severidad del workflow que falló:

Opción A: Por nombre del workflow

{{
  $json.workflow.name.includes('[PROD-CRITICAL]') ? 'critical' :
  $json.workflow.name.includes('[PROD]') ? 'high' :
  $json.workflow.name.includes('[STAGING]') ? 'medium' :
  'low'
}}

Convención de nombres marca la severidad.

Opción B: Sheet con configuración

Mantienes Sheet workflow_metadata:

workflow_id	severity
abc123	critical
def456	high
...	...

El Error Workflow lee este Sheet y busca el workflow_id que falló.

Pros: flexibilidad, fácil cambiar severidad sin renombrar workflows. Contras: mantener Sheet sincronizado.

Patrones de notificación

Pattern 1: Severidad → canal

critical → Slack #urgente + Email + SMS
high     → Slack #alerts + Email
medium   → Slack #alerts
low      → Sheet log

Pattern 2: Suppresión de duplicados

Si el mismo workflow falla 100 veces en 1 hora, no enviar 100 Slacks.

Implementación:

[Error Trigger]
   │
[Sheet: buscar errores recientes del mismo workflow en últimos 60 min]
   │
[IF: count < 3]
├─ TRUE → notificar normal
└─ FALSE → log silencioso (suppression)

Pattern 3: Escalation

Si un error sigue ocurriendo por X tiempo, escalar:

1 hora: Slack al equipo
2 horas: Slack manager
4 horas: SMS + email a admin
8 horas: Llamar oncall

Implementación con Sheet de tracking + IFs.

Información que SIEMPRE incluir en alerts

Al diseñar el mensaje de notificación:

Imprescindible

Workflow name (cuál falló)
Nodo que falló (dónde)
Mensaje de error (qué)
Timestamp (cuándo)
Link a execution (para investigar inmediato)

Útil

Severidad (visual: emoji 🚨/⚠️/ℹ️)
Últimos 3 errores del mismo workflow (¿es recurrente?)
Mention del responsable (@usuario en Slack)

NO incluir

Datos sensibles (passwords, PII)
Payloads completos (puede tener info sensible y ser ruido)
Cualquier cosa que viole privacy/security

Múltiples Error Workflows

Para organizaciones con muchos workflows productivos, considera varios Error Workflows especializados:

[GUARDIAN-PROD]: para producción crítica → notifications agresivas
[GUARDIAN-STAGING]: para staging → solo log, sin spam
[GUARDIAN-CLIENT-X]: específico para workflows de cliente X → notifica al equipo de ese cliente

Cada workflow productivo asigna el Error Workflow apropiado.

Error Workflow tests

Importante: test que tu Error Workflow funciona.

Método 1: Causar error intencional

En un workflow de prueba, agregar un nodo que siempre falla:

HTTP Request a URL inválida
Set con expression que da error

Verificar que Error Workflow se dispara y notifica correctamente.

Método 2: Test mode con Error Trigger

n8n permite ejecutar manualmente un workflow con Error Trigger pasando datos mock.

Verifica que el formato del mensaje sea correcto antes de poner en producción.

Trampas comunes

Trampa 1: Error Workflow que también falla

Qué pasa: Error Workflow tiene un Slack node. Slack está caído. Error Workflow falla. Quién te avisa?

Cómo evitar:

Notificar por 2 canales independientes (Slack + Email)
Error Workflow simple y robusto (menos cosas que puedan fallar)

Trampa 2: Error Workflow no asignado a workflows productivos

Qué pasa: Diseñaste un Error Workflow excelente. No lo asignaste a tus workflows productivos. Cuando algo falla, no se dispara.

Cómo evitar:

Hábito profesional: al activar un workflow productivo, último paso es asignar Error Workflow
Revisar periódicamente que todos los workflows productivos tienen Error Workflow asignado

Trampa 3: Demasiado verboso

Qué pasa: Cada error pequeño genera Slack alert. Canal saturado. Equipo deja de mirar.

Cómo evitar:

Severidad apropiada
Suppression para duplicados
Solo notify lo que realmente requiere acción

Trampa 4: Error Workflow asume contexto

Qué pasa: Error Workflow muestra "Error en nodo HTTP". Pero hay 5 workflows con nodo HTTP. ¿Cuál?

Cómo evitar: Siempre incluir workflow name en la notification.

Resumen

Error Workflow + Error Trigger = automatic notification de fallos
Diseñar para severidad apropiada (crítica vs baja)
Detectar severidad por nombre o Sheet de config
Patterns: severidad-canal, suppression, escalation
Info imprescindible: workflow, nodo, error, timestamp, link
Múltiples Error Workflows para casos especializados
Test que funciona antes de confiar
4 trampas: Error Workflow que falla, no asignado, demasiado verboso, sin contexto

Lo que sigue: Fallback paths — qué hacer cuando algo crítico falla y aún quieres dar valor.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorPatrones de Continue on Fail Siguiente →Rutas de respaldo (fallback)