Tres formas de fallar, y solo una avisa
Una automatización puede dejar de hacer su trabajo de tres maneras. Puede reventar: una llamada devuelve un error, el nodo se detiene y la ejecución queda marcada como fallida. Puede no arrancar: el disparador deja de dispararse porque caducó una credencial, cambió un webhook o alguien desactivó el flujo, y entonces no hay ejecución que fallar. Y puede terminar en verde sin haber hecho nada útil: un filtro que ya no coincide, una consulta que devuelve cero filas, un modelo que responde con la forma correcta y el contenido equivocado.
Las plataformas avisan bien del primero y prácticamente nada de los otros dos. Ese es el problema: los fallos que más tardan en detectarse no son los que dan error, son los que no lo dan.
El fallo ruidoso: lo que la plataforma ya te da
Conviene agotar primero lo que viene de serie: no cuesta nada y mucha gente no lo tiene activado.
En n8n cada flujo puede declarar en sus ajustes un flujo de error, que se ejecuta cuando una ejecución falla. Empieza con un nodo Error Trigger y recibe el identificador y la URL de la ejecución, el mensaje de error, la traza, el último nodo ejecutado y el nombre del flujo. Un mismo flujo de error sirve para todos los demás, así que se monta una vez.
Su documentación declara dos límites. El Error Trigger solo se dispara en ejecuciones automáticas, nunca al lanzar el flujo a mano, así que no se puede probar de la forma obvia. Y el identificador y la URL de la ejecución no aparecen si el fallo ocurre en el propio nodo disparador o si la ejecución no llegó a guardarse.
En Zapier el equivalente es la repetición de ejecuciones: en el plan gratuito se repiten a mano las que quedaron en estado de error, y en los de pago hay repetición automática y se pueden repetir además las que quedaron en espera. Repetir no es detectar, pero recorta cuántas incidencias llegan a verse.