Nodo Stop and Error n8nConfigura Stop and Error en n8n.

El primer uso aparece detrás de una llamada a una API. Un nodo HTTP Request devuelve una respuesta técnicamente correcta pero inservible, una lista vacía donde esperabas un registro. Stop and Error convierte ese caso silencioso en un fallo visible, mucho más fácil de detectar que una ejecución que acabó sin producir nada.

El segundo uso es el de barrera. Un flujo arranca con un Webhook, es decir una URL que un servicio externo llama para dejar datos dentro de n8n, y a veces esos datos llegan sin el identificador que necesita todo lo que viene después. Un nodo If revisa el campo, la rama falsa cae en Stop and Error y la ejecución se detiene ahí, en vez de escribir una fila incompleta tres nodos más adelante.

El tercer uso tiene que ver con avisar a quien toca. Con la opción errorObject lanzas un objeto estructurado en lugar de una frase, y el flujo que reacciona al fallo puede leer sus propiedades una a una. La documentación de n8n describe esa pareja: el nodo Error Trigger arranca un flujo de error y la información personalizada que lanzaste viaja con él. Con un código y una descripción ya puedes decidir si el aviso va al equipo técnico o al de operaciones antes de llegar a Slack.

Hay ramas donde conviene otro nodo. Switch gestiona más de dos salidas y las mantiene todas vivas, útil cuando la rama todavía tiene una continuación válida, algo que ya no ocurre cuando el flujo llega a Stop and Error.

Los límites son cortos de contar. El nodo expone un solo parámetro, así que no hay nada que ajustar más allá del error que escribes. Se ejecuta sobre cada item entrante y nunca abre un flujo por su cuenta: delante siempre va un Schedule Trigger, un Webhook o el trigger de una herramienta. Si todavía estás comparando plataformas antes de montar tu gestión de errores, la Reseña n8n cubre el terreno alrededor de este nodo.