Nodo Error Trigger n8nConfigura Error Trigger en n8n.

El montaje más habitual es el aviso. Detrás del Error Trigger, un mensaje cae en el canal donde el equipo ya está mirando con Slack, o llega por Gmail cuando la persona responsable vive en su bandeja de entrada. Un fallo deja de ser algo que descubres tres días después revisando la lista de ejecuciones.

El segundo montaje es el registro. En lugar de un aviso que se pierde, una fila por fallo en Postgres cuando el volumen pesa, o una hoja en Google Sheets si el equipo prefiere mirarlo sin consultas. A las pocas semanas ese registro responde algo que un aviso suelto nunca aclara: qué automatización se rompe a menudo y cuál se rompió una vez.

El tercero pasa el fallo a un sistema que ya lleva el seguimiento del trabajo. Una llamada con HTTP Request alcanza cualquier endpoint HTTP, así que una herramienta de incidencias o una API interna recibe el fallo sin que nadie copie nada a mano. Ese nodo es el recurso cuando a un nodo dedicado le falta una operación de API HTTP, nunca para hablar un protocolo que no sea HTTP.

¿Cuándo conviene no usarlo? Cuando el fallo tiene nombre y lo puedes resolver dentro del propio flujo que lo provoca, con los datos todavía en la mano. El Error Trigger cubre lo demás, lo que nadie había previsto. Hay una condición que lo decide todo, y no es un ajuste: el flujo que abre tiene que estar activo para escuchar en producción. En el editor, una ejecución de prueba lanza una escucha puntual, suficiente para validar el montaje y no para cubrirte de madrugada.

Las limitaciones se ven enseguida. Cero parámetros significa cero filtros y cero niveles de gravedad dentro del nodo: todo lo que llega a ese workflow de errores entra por la misma puerta y el reparto se hace después, en los nodos que añadas. El workflow de errores puede ser cualquier flujo de la instancia, de modo que un montaje compartido casi siempre gana a uno por automatización. Si quieres ver cómo encajan trigger, activación y ejecuciones, el Curso n8n lo recorre entero.