Los que gestionan flujos de trabajo en n8n para clientes — ¿cómo se enteran cuando algo se rompe?

Describe el problema/error/pregunta

Ejecuto automatizaciones en n8n para algunos clientes, y la parte que me estresa no es construir — es no saber cuándo algo se rompe silenciosamente.

¿Cuál es el mensaje de error (si es que hay)?

Por favor comparte tu flujo de trabajo

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte el resultado devuelto por el último nodo

Información sobre tu configuración de n8n

  • Versión de n8n:
  • Base de datos (por defecto: SQLite):
  • Configuración de n8n EXECUTIONS_PROCESS (por defecto: own, main):
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:
1 me gusta

Texto sin formato

¡Hola! Esto es completamente comprensible. El escenario de «ruptura silenciosa» es exactamente lo que mantiene despiertos a los arquitectos de automatización, especialmente cuando se gestionan flujos de trabajo de clientes.

La mejor y más escalable forma de manejar esto en n8n no es añadiendo lógica de manejo de errores a cada flujo de trabajo individual, sino creando un único **Flujo de Trabajo de Error Global** centralizado.

n8n tiene un nodo dedicado `Error Trigger`. Cuando se configura en un flujo de trabajo independiente, actúa como un escucha global. Siempre que *cualquier* flujo de trabajo activo en tu instancia de n8n falle, este disparador lo captura y extrae todos los metadatos (nombre del flujo de trabajo, nodo que falló, mensaje de error, ID de ejecución).

Aquí hay una plantilla lista para usar para un Notificador de Error Global. Solo copia este JSON y pégalo en un flujo de trabajo nuevo en blanco:

```json
{
  "nodes": [
    {
      "parameters": {},
      "type": "n8n-nodes-base.errorTrigger",
      "typeVersion": 1,
      "position": [240, 240],
      "id": "2498e94e-d00d-4054-9988-518201a052e4",
      "name": "Error Trigger (Catch All)"
    },
    {
      "parameters": {
        "mode": "json",
        "json": {
          "workflowName": "={{ $json.context.workflow.name }}",
          "workflowId": "={{ $json.context.workflow.id }}",
          "executionId": "={{ $json.context.execution.id }}",
          "errorNodeName": "={{ $json.error.context.node.name }}",
          "errorMessage": "={{ $json.error.message }}",
          "timestamp": "={{ new Date().toISOString() }}"
        },
        "options": {}
      },
      "type": "n8n-nodes-base.set",
      "typeVersion": 1,
      "position": [480, 240],
      "id": "e914041a-a131-4a4b-8526-a05d6888c3a5",
      "name": "Format Error Data"
    },
    {
      "parameters": {
        "fromEmail": "n8n@yourdomain.com",
        "toEmail": "youremail@yourdomain.com",
        "subject": "🚨 n8n Workflow Failed: {{ $json.workflowName }}",
        "text": "Hola,\n\nUn flujo de trabajo de n8n ha fallado inesperadamente.\n\n----------------------------------------\nNombre del flujo de trabajo: {{ $json.workflowName }}\nID del flujo de trabajo: {{$json.workflowId }}\nID de ejecución: {{ $json.executionId }}\nNodo que falló: {{$json.errorNodeName }}\nMensaje de error: {{ $json.errorMessage }}\nMarca de tiempo: {{$json.timestamp }}\n----------------------------------------\n\nPor favor, verifica las ejecuciones de tu instancia de n8n.",
        "options": {}
      },
      "type": "n8n-nodes-base.emailSend",
      "typeVersion": 1,
      "position": [720, 240],
      "id": "766a2673-8181-4200-a07c-95c52c035661",
      "name": "Email Send (Error Alert)"
    }
  ],
  "connections": {
    "Error Trigger (Catch All)": {
      "main": [
        [
          {
            "node": "Format Error Data",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Format Error Data": {
      "main": [
        [
          {
            "node": "Email Send (Error Alert)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

Cómo usarlo:

  1. Pega esto en un flujo de trabajo nuevo.

  2. Abre el nodo Email Send (o reemplázalo con un nodo de Slack/Discord si prefieres alertas de chat).

  3. Conecta tus credenciales de correo electrónico y establece tu toEmail.

  4. Activa este flujo de trabajo.

Ahora no tienes que preocuparte. Si algo falla silenciosamente, recibirás instantáneamente un correo electrónico con los detalles exactos de qué se rompió y dónde.

Following up on this since a few people asked how I ended up detecting these.

The short version: n8n’s execution status alone misses an entire class. A node set to continue-on-fail records its error inside data.resultData.runData[nodeName][].error while the run still reports success. You need includeData=true to see it at all.

I wrote up what I found, including two classification mistakes that took me a while to notice — one of them being that a dead Google credential often surfaces with no HTTP code at all: Why n8n says a workflow succeeded when it didn't — Okum

If anyone has hit a failure shape that doesn’t fit, I’d like to hear it.

1 me gusta

The failure the Error Trigger can’t see is the one that actually burns you: a workflow that never runs. If a trigger silently dies or Cloud auto-deactivates after a hard crash, nothing errors, so nothing alerts.

I’d pair the global Error Trigger with one heartbeat workflow on a schedule that hits the public API per client flow — GET /api/v1/executions?workflowId=… and compare the newest startedAt against the window that flow is supposed to run in, plus GET /api/v1/workflows/{id} to confirm active is still true. One catches loud failures, the other catches silence.

The silence case is the one I keep coming back to as well, and your split is right — one catches loud failures, the other catches absence.

One cause of it that surprised me: a workflow can be deployed and simply never activate, with no error anywhere. I hit this with form and webhook triggers — deploy the same template to a second client and both copies claim the same URL path, so n8n refuses to activate the second one. It shows as saved and looks fine in the list, but it has never run once. GET /api/v1/workflows/{id} and checking active is the only thing that catches it, exactly as you said.

Worth checking that alongside the heartbeat, since a workflow that never activated has no startedAt to compare against at all — there’s no history to notice a gap in.

Have you found a reliable window per workflow, or do you set the expected interval by hand per client? That’s the part I haven’t solved — a flow that runs hourly and one that runs on a form submission need very different definitions of “too quiet.”