4. Dónde deben alertar los fallos

Descripción

Al terminar esta lección vas a poder decidir, para cada fallo de tu sistema, si merece una alerta que interrumpe a una persona o solo un log que se revisa después. Vas a distinguir la señal del ruido: el fallo transitorio que se cura solo contra el fallo terminal que necesita un humano. Vas a entender la fatiga de alertas —por qué alertar de todo es la forma más rápida de que nadie mire ninguna alerta— y vas a aprender a definir qué es un fallo "real" para cada uno de los workflows de Cumbre, quién es el dueño que responde, y con qué nivel de urgencia. Esta lección es sobre la decisión de diseño, no sobre la herramienta: no vamos a conectar un canal de Slack ni a montar un dashboard —eso es operación—; vamos a decidir qué merece avisar y a quién, que es lo que ninguna herramienta decide por ti.

Esto importa porque una alerta mal calibrada es peor que ninguna. Si tu sistema avisa cada vez que una API tarda un segundo de más, en dos semanas el equipo aprende a ignorar esos avisos, y el día que llega la alerta que sí importaba —un reembolso atascado, dinero en el limbo— está enterrada entre cuarenta avisos irrelevantes que nadie leyó. La confiabilidad no es solo que el sistema se recupere solo; es que, cuando no puede recuperarse solo, la persona correcta se entere a tiempo y con la urgencia correcta. Eso no se logra con una herramienta. Se logra con una decisión, y esta lección es esa decisión.

Conexión con el módulo: las lecciones 2 y 3 fueron las reacciones automáticas al fallo —reintentar y compensar—. Esta es la reacción humana: cuándo un fallo trasciende lo que la máquina puede resolver y hay que despertar a alguien. Es la bisagra entre lo automático y lo manual. Se apoya en todo lo anterior: un fallo que un reintento cura (lección 2) no alerta; una compensación que funciona (lección 3) tampoco; pero una compensación que falla —el caso con el que cerró la lección 3— sí, porque ya nadie más va a resolverlo. La lección 5 construye la maquinaria que ejecuta esta decisión: el error workflow que enruta el fallo y decide, según lo que definas aquí, si alerta o solo registra.

Señal contra ruido: no todo fallo es una emergencia

Empecemos por la distinción que gobierna toda la lección, con una imagen.

Piensa en los sensores de una casa. Hay un detector de humo: cuando suena, dejas lo que estás haciendo y vas a ver, porque podría ser un incendio. Y hay un foco que parpadea cuando un electrodoméstico terminó su ciclo: lo notas cuando pasas por ahí, y si no lo notas ahora, no pasa nada, lo verás luego. Los dos son señales de que "algo ocurrió". Pero uno interrumpe tu vida y el otro espera. Nadie llama a los bomberos porque se quemó una tostada, y nadie deja que la casa se incendie porque "ya me acostumbré a que ese sensor suene".

El error más común en el manejo de alertas es tratar todos los fallos como detectores de humo. Cada timeout, cada respuesta lenta, cada tropiezo transitorio dispara una notificación urgente. Y como la enorme mayoría de esos fallos se curan solos —un reintento, una compensación—, la mayoría de las "emergencias" resultan ser tostadas quemadas. El equipo aprende, con toda la razón, que el detector miente. Y un detector que miente es peor que no tener detector, porque da una falsa sensación de cobertura mientras entrena a todos a ignorarlo.

La distinción concreta que vas a usar es esta:

• Fallo transitorio: un tropiezo pasajero que se resuelve por sí solo o con un reintento. Un timeout de red, un 503 temporal, un servicio saturado un instante. No necesita a nadie. Es el foco que parpadea: se registra en un log, y si un patrón de muchos fallos transitorios apareciera, eso sí merecería mirarse —pero un fallo transitorio aislado, no—.
• Fallo terminal: un fallo que ningún mecanismo automático va a resolver, y que deja el sistema en un estado que requiere una decisión humana. Una compensación que agotó sus reintentos, un reembolso que no se pudo emitir, un pedido cobrado sin surtir. Es el detector de humo: alguien tiene que enterarse ahora.

Casi todo el arte de las alertas es clasificar bien cada fallo en una de estas dos categorías. Y la mayoría de los fallos de un sistema bien diseñado —con los reintentos de la lección 2 y las compensaciones de la lección 3— caen del lado transitorio. Las alertas de verdad deberían ser pocas, justamente porque las demás piezas del módulo ya resolvieron el resto.

La fatiga de alertas, y por qué mata sistemas

Vale la pena detenerse en el fenómeno, porque tiene nombre y es la causa número uno de que los sistemas de alertas fracasen.

La fatiga de alertas es lo que le pasa a un equipo cuando recibe tantas alertas que deja de prestarles atención. No es pereza ni descuido: es una respuesta racional. Si de cada cien alertas noventa y ocho no requieren que hagas nada, tu cerebro aprende —correctamente— que la probabilidad de que la próxima importe es baja, y baja tu guardia. El problema es que las dos que sí importaban se pierden con las demás.

En un sistema de Cumbre esto se ve así: alguien conecta "avísame de cualquier ejecución fallida" a un canal. Al principio se revisa cada una. Pero resulta que la API de crédito da timeout tres o cuatro veces al día —y se recupera sola cada vez, gracias a los reintentos—, así que llegan tres o cuatro alertas diarias de algo que ya se resolvió antes de que nadie las leyera. Súmale los fallos transitorios de inventario, los reintentos de reembolso que funcionaron al segundo intento, y en poco tiempo el canal tiene decenas de mensajes al día, todos diciendo "falló algo" sobre cosas que ya no están falladas. La persona deja de abrirlo. Y el día que un reembolso de verdad se atasca, la alerta llega al mismo canal muerto.

La lección práctica es contraintuitiva pero firme: menos alertas es más seguro que más alertas. Una alerta debe ser tan rara y tan confiable que, cuando llega, la persona sepa sin dudar que tiene que actuar. Ese es el estándar. Si tu canal de alertas recibe más de un puñado de mensajes al día, y la mayoría no llevan a ninguna acción, no tienes un sistema de alertas: tienes ruido con el que entrenaste a tu equipo a no mirar.

Por eso esta lección va antes de conectar cualquier herramienta. La tentación de "conéctalo todo y ya veremos" es exactamente la que produce fatiga. Primero decides qué merece alertar. Después, y solo después, conectas.

Las tres preguntas de diseño para cada workflow

Para cada workflow de tu sistema, tres preguntas te dan su política de alertas. Vamos a responderlas para Cumbre.

Pregunta 1: ¿Qué es un fallo "real" para este workflow? No todo error técnico es un fallo real. Un check-credit que responde "crédito rechazado" no falló: hizo su trabajo, la respuesta es un no. Un check-credit que da timeout y se recupera al reintentar tampoco es un fallo real: es un tropiezo que se curó. Un fallo real es el que deja algo sin resolver que importa. Definirlo obliga a separar el error técnico del problema de negocio.

Pregunta 2: ¿Quién es el dueño que responde? Una alerta sin destinatario claro es una alerta que nadie atiende, porque "es de todos" significa "es de nadie". Cada workflow necesita un dueño: la persona o el rol que, cuando ese workflow falla de verdad, es responsable de actuar. En Cumbre —doce personas— probablemente sea el encargado de operaciones para los pedidos, y quien maneje las finanzas para los reembolsos. El punto no es el organigrama; es que alguien con nombre recibe la alerta y sabe que es suya.

Pregunta 3: ¿Con qué urgencia? No todos los fallos reales tienen la misma prisa. Un reembolso atascado —dinero en el limbo— es urgente: se atiende hoy. Un pedido que quedó en la cola de mensajes muertos por un dato mal formado puede esperar a que alguien revise la cola en su horario normal. La urgencia decide el canal y el momento: lo urgente interrumpe; lo importante-pero-no-urgente se acumula para revisar.

Ejemplo trabajado: la política de alertas de Cumbre

Apliquemos las tres preguntas a los cuatro workflows, y saquemos una tabla que es, literalmente, el diseño de alertas del sistema.

order-triage. ¿Qué es un fallo real? Que un pedido no se pueda ni siquiera evaluar: un evento que llega tan mal formado que no pasa la validación del contrato (Módulo 3), o que la conexión al ledger esté caída y no se pueda deduplicar. Un webhook que dispara dos veces no es un fallo —el dedup lo absorbe en silencio—. ¿Quién responde? Operaciones. ¿Urgencia? Media: un pedido que no se pudo evaluar hay que revisarlo, pero no despierta a nadie de madrugada; va a la cola de mensajes muertos y se revisa en el día.

check-credit. ¿Qué es un fallo real? No el timeout que se recupera al reintentar —ese es transitorio, ni siquiera se registra como alerta—. No el "crédito rechazado" —esa es una respuesta de negocio legítima que sigue su propio camino—. El fallo real es que la API de crédito esté caída de forma sostenida, agotando todos los reintentos de varios pedidos seguidos: eso ya no es un tropiezo, es un servicio abajo. ¿Quién responde? Operaciones, quizás con soporte técnico. ¿Urgencia? Alta si son muchos pedidos: el sistema no puede procesar nada.

inventory-sync. ¿Qué es un fallo real? Que la reserva falle por un error técnico persistente —no por falta de stock, que es una respuesta de negocio normal que dispara la compensación de la lección 3—. ¿Quién responde? Operaciones. ¿Urgencia? Media.

issue-refund. ¿Qué es un fallo real? Que un reembolso o una liberación de retención no se pueda ejecutar tras agotar los reintentos. Este es el detector de humo del sistema: es dinero atrapado o crédito bloqueado que ningún mecanismo automático va a soltar. ¿Quién responde? Finanzas, con nombre y apellido. ¿Urgencia? Alta, siempre. Un reembolso atascado es la clase de fallo que interrumpe.

La tabla resultante:

Workflow	Fallo real	Transitorio (solo log)	Dueño	Urgencia si es real
order-triage	Pedido no evaluable (contrato/ledger)	Webhook doble; validación de un item aislado	Operaciones	Media (revisar en el día)
check-credit	API de crédito caída sostenidamente	Timeout que se recupera; crédito rechazado	Operaciones + técnico	Alta si son varios pedidos
inventory-sync	Error técnico persistente en la reserva	Falta de stock (dispara compensación)	Operaciones	Media
issue-refund	Reembolso/liberación que no se ejecuta	Reintento que funciona al segundo intento	Finanzas	Alta, siempre

Qué esperar de esta política. En un día normal, con reintentos y compensaciones haciendo su trabajo, esta política produce cero o una alerta. Casi todo cae del lado transitorio y se registra sin molestar a nadie. Las alertas que llegan son raras y confiables: cuando suena la de issue-refund, finanzas sabe que hay dinero real que atender, sin dudarlo. Compara eso con "avísame de todo", que en el mismo día habría producido diez o quince mensajes, la mayoría de tostadas quemadas. La diferencia no es la herramienta —las dos usan el mismo canal—; es la decisión que hiciste antes de conectarla.

Niveles de severidad: no todo lo que alerta, interrumpe

Una vez que separaste transitorio de real, conviene un matiz más dentro de los fallos reales: no todos merecen el mismo canal. Un esquema de tres niveles cubre casi cualquier sistema:

• Crítico (interrumpe): dinero o datos en riesgo, o el sistema entero detenido. Va a un canal que la gente mira aunque sea fin de semana. En Cumbre: un reembolso atascado, la API de crédito caída para todos los pedidos. Deberían ser rarísimos.
• Advertencia (se revisa pronto, no interrumpe): algo quedó sin resolver pero no se está desangrando. Va a un canal que se revisa en horario laboral. En Cumbre: un pedido en la cola de mensajes muertos por un dato mal formado.
• Informativo (solo log): los fallos transitorios y los eventos normales. No va a ningún canal humano; se registra por si algún día quieres analizar patrones. En Cumbre: cada timeout que se recuperó, cada webhook duplicado que el dedup absorbió.

La razón de tener niveles es que el canal comunica la urgencia sin que nadie tenga que leer el detalle. Cuando algo llega al canal crítico, la persona ya sabe —por el canal— que suelte lo que está haciendo. Cuando llega al de advertencia, sabe que puede terminar lo que hace y luego revisar. El nivel es, él mismo, información.

Un detalle que importa: el nivel no es una propiedad fija del error, es una decisión tuya sobre ese error en tu negocio. Un reembolso atascado es crítico para Cumbre porque involucra dinero de clientes. En otro negocio, el mismo tipo de fallo técnico podría ser una advertencia. No hay una tabla universal; hay tu criterio sobre qué le duele a tu sistema. Eso es exactamente lo que hace de esto una decisión de diseño y no una configuración.

Del fallo aislado al patrón: cuando muchos transitorios se vuelven señal

Hay un matiz que evita un malentendido. Dijimos que un fallo transitorio aislado no alerta. Pero muchos fallos transitorios seguidos sí son una señal, y conviene entender por qué no se contradicen.

Un timeout de la API de crédito es una tostada quemada: pasa, se recupera, no importa. Pero cuarenta timeouts de la API de crédito en cinco minutos ya no es una tostada quemada: es el olor a que algo se está incendiando de verdad. Cada uno, por separado, se recuperó con su reintento —así que ninguno individualmente es un fallo terminal—. Pero el ritmo al que ocurren dice que la API está degradándose, y eso sí merece que alguien mire antes de que empiece a agotar reintentos y a caerse del lado terminal.

Esta es la diferencia entre alertar por un evento y alertar por una tasa. La política que diseñaste hasta ahora alerta por eventos terminales concretos: este reembolso se atascó. Una capa más fina alerta por tasas: "más de N fallos transitorios del mismo tipo en M minutos". La primera es fácil de montar dentro de n8n con lo que vas a ver en la lección 5. La segunda —contar fallos en una ventana de tiempo y disparar cuando cruzan un umbral— es más natural en una herramienta de observabilidad que agrega métricas, y por eso vive del lado de la operación, en la guía de producción.

Lo que importa que te lleves: el mismo fallo puede ser ruido cuando es aislado y señal cuando es un patrón. Tu log informativo —donde mandas los transitorios— no es un basurero; es el material con el que después se detectan patrones. Registrar los transitorios en vez de descartarlos es lo que hace posible, más adelante, notar que "la API de crédito falla mucho más los lunes" y hacer algo al respecto. No alertes por cada uno; pero no los tires.

Cómo se ve una alerta útil

Una decisión de diseño que se olvida: qué dice la alerta cuando llega. Una alerta que solo dice "algo falló en Cumbre" obliga al que la recibe a ir a investigar desde cero, y eso es fricción que atrasa la respuesta justo cuando importa.

Una alerta útil le da al dueño, de un vistazo, lo que necesita para decidir qué hacer:

• Qué falló y de qué workflow. No "error en el sistema", sino "issue-refund no pudo emitir el reembolso del pedido ORD-3180".
• El identificador para rastrearlo. El order_id, y de ser posible el enlace a la ejecución concreta que falló, para que el dueño llegue directo al detalle sin buscar.
• Qué ya intentó el sistema. "Se agotaron los tres reintentos" le dice al dueño que esto no se va a arreglar solo, y que su intervención es necesaria.
• Dónde quedó guardado. "El item está en la cola de mensajes muertos" le dice que nada se perdió y que tiene tiempo de decidir con calma.

Fíjate en que toda esa información sale de piezas que ya tienes: el order_id viene del pedido, el workflow que falló lo sabe el Error Trigger (lección 5), el estado de los reintentos y la cola de mensajes muertos son las lecciones 2 y 5. La alerta útil no requiere datos nuevos; requiere decidir incluirlos en el mensaje en vez de mandar un "falló algo" pelón. Es la diferencia entre una alerta que acelera la respuesta y una que solo avisa que hay trabajo por delante.

Dónde termina esta lección: la decisión, no el dashboard

Vale la pena marcar el límite explícito, porque es fácil cruzarlo sin darse cuenta —y la lección 7 lo va a formalizar para todo el módulo—.

Lo que esta lección diseña es la política: qué fallo alerta, quién lo recibe, con qué urgencia. Eso es correctitud: define cómo debe comportarse el sistema ante un fallo.

Lo que esta lección no hace es montar la infraestructura de observabilidad: un dashboard con gráficas del volumen de errores en el tiempo, integración con una herramienta de monitoreo externa, agregación de métricas, paneles que el equipo mira todo el día. Eso es operación, y vive en n8n-production-maintenance-guide. La distinción es la misma de siempre: aquí decides que un reembolso atascado debe alertar a finanzas con urgencia alta; allá se construye el tablero donde finanzas ve el histórico de cuántos reembolsos se atascaron este mes.

Por qué insisto: es tentador, al hablar de alertas, saltar directo a "y lo conecto a tal herramienta y hago tal gráfica". Pero si conectas la herramienta antes de decidir la política, terminas con la fatiga de alertas del principio de la lección. El orden correcto es: primero la decisión (esta lección), después la maquinaria que la ejecuta dentro de n8n (lección 5), y solo mucho después —en la otra guía— la infraestructura de observabilidad de producción. No inviertas el orden.

Una nota para equipos chicos, que es el caso de Cumbre con sus doce personas. Cuando "el dueño que responde" y "quien construyó el workflow" son la misma persona —o cuando el equipo entero cabe en un canal—, es fácil pensar que la política de alertas sobra: "total, nos enteramos igual". Es al revés. Cuanto más chico el equipo, más duele la fatiga de alertas, porque no hay un turno de guardia que reparta la carga: la misma persona recibe todo, y si recibe ruido todo el día, se quema o desconecta. Un solo dueño necesita, más que nadie, que su canal de alertas sea raro y confiable, para poder ignorarlo con tranquilidad el 99% del tiempo y confiar en que cuando suene, es de verdad. La política de esta lección no es un lujo de empresas grandes; es especialmente valiosa cuando eres pocos.

Errores comunes

Alertar de cada ejecución fallida (conceptual). Qué pasa: se conecta "notifícame de toda ejecución que falle" a un canal, con la intención de no perderse nada. En dos semanas llegan decenas de alertas al día, casi todas de fallos transitorios ya resueltos, y el equipo deja de mirar el canal. Por qué pasa: es la opción más fácil de configurar y la que se siente más segura —"así cubro todo"—. Cómo detectarlo: cuenta cuántas alertas recibes al día y qué fracción llevó a una acción; si la mayoría no requirieron que nadie hiciera nada, tienes fatiga en curso. Cómo corregirlo: aplica las tres preguntas de diseño a cada workflow antes de conectar nada, y alerta solo de los fallos reales, mandando los transitorios a un log que nadie mira salvo para analizar patrones. Menos alertas, más confiables.

Confundir un resultado de negocio con un fallo (conceptual). Qué pasa: se trata "crédito rechazado" o "sin stock" como errores del sistema y se alerta de ellos. Pero un cliente sin línea de crédito no es un fallo: es una respuesta legítima que el negocio debe manejar de otra forma —quizás avisándole al cliente, no despertando a un ingeniero—. Por qué pasa: técnicamente, esos casos a veces se implementan como una rama de "error", y de ahí se cuelan a las alertas. Cómo detectarlo: revisa tus alertas y pregúntate, para cada una, "¿esto es algo que se rompió, o es el sistema funcionando y dando una respuesta que no nos gusta?". Cómo corregirlo: enruta los resultados de negocio con un nodo If o Switch hacia su propio flujo —"pedido no surtido por crédito", "pedido en espera por stock"—, y reserva las alertas técnicas para lo que de verdad se rompió.

Alertar sin un dueño con nombre (práctico). Qué pasa: la alerta llega a un canal general "de todos", y cuando algo importante falla, cada quien asume que otro lo está viendo, y nadie actúa. Por qué pasa: es más cómodo mandar todo a un canal común que asignar responsables. Cómo detectarlo: para cada alerta crítica de tu sistema, pregúntate "si esto suena a las 2 de la tarde, ¿quién exactamente deja lo que está haciendo?". Si la respuesta es "alguien del equipo", no hay dueño. Cómo corregirlo: asigna a cada workflow un dueño concreto para sus fallos reales, y haz que la alerta lo mencione o le llegue directo. Una alerta sin dueño es una alerta que se atiende a veces, que es casi tan malo como no tenerla.

Ejercicios

Ejercicio 1 — Transitorio o terminal. Clasifica cada uno de estos seis fallos de Cumbre como "transitorio (solo log)" o "terminal (alerta)", y en una frase por qué:

(a) La API de crédito da timeout y responde bien al segundo intento. (b) El webhook de un pedido disparó tres veces en un segundo. (c) issue-refund agotó sus tres reintentos y no pudo emitir un reembolso. (d) check-credit respondió "crédito rechazado" para un cliente moroso. (e) La conexión al Postgres del ledger lleva diez minutos caída y ningún pedido se puede deduplicar. (f) Un pedido llegó con el campo amount en blanco y no pasó la validación del contrato.

Ver solución

(a) Transitorio. Se curó solo con el reintento. Se registra en el log informativo; no alerta a nadie. Si muchos timeouts así se acumularan, el patrón sería otra cosa —pero uno aislado, no—.

(b) Transitorio, y ni siquiera un fallo. El dedup del ledger lo absorbe: el segundo y tercer disparo no hacen nada. No merece log de error siquiera, a lo sumo una traza informativa.

(c) Terminal. Ningún mecanismo automático va a resolverlo, y hay dinero en el limbo. Alerta crítica a finanzas, urgencia alta. Es el detector de humo del sistema.

(d) Ni transitorio ni terminal: no es un fallo. Es una respuesta de negocio legítima. No va a las alertas técnicas en absoluto; sigue su propio flujo —avisar al cliente, no surtir el pedido—.

(e) Terminal. El sistema entero está detenido: sin ledger no hay dedup y nada avanza. Alerta crítica, urgencia alta, probablemente a operaciones y a quien maneje la infraestructura.

(f) Terminal pero de baja urgencia. El pedido no se pudo evaluar y no queremos perderlo, así que va a la cola de mensajes muertos y genera una advertencia que se revisa en el día. No interrumpe a nadie, pero no se ignora.

Por qué funciona: fíjate en que de seis fallos, solo tres merecen una alerta, y solo dos son urgentes. Los otros tres son ruido (a, b) o ni siquiera fallos (d). Esa proporción —pocas alertas reales entre muchos eventos— es la marca de un sistema bien calibrado. Si clasificaras los seis como "alerta", tendrías fatiga garantizada.

Ejercicio 2 — Asigna severidad y dueño. Para los tres fallos que en el ejercicio anterior clasificaste como terminales (c, e, f), asigna un nivel de severidad (crítico / advertencia / informativo) y un dueño, y di a qué tipo de canal iría cada uno.

Ver solución

(c) Reembolso que no se pudo emitir: crítico, dueño finanzas, canal que se mira aunque sea fin de semana. Hay dinero de un cliente atrapado; se atiende hoy.

(e) Ledger caído diez minutos: crítico, dueño operaciones + técnico, canal que interrumpe. El sistema entero está parado; cada minuto son pedidos que no se procesan.

(f) Pedido con amount en blanco en la cola de mensajes muertos: advertencia, dueño operaciones, canal que se revisa en horario laboral. El pedido está guardado y no se pierde; alguien lo revisará y decidirá —quizás pedirle el dato al cliente— sin prisa.

La diferencia clave entre (c)/(e) y (f): los dos primeros involucran dinero o el sistema entero, y no esperan; el tercero está a salvo en la cola y puede esperar a un horario normal. El canal comunica esa diferencia sin que nadie lea el detalle.

Por qué funciona: separar severidad de "es un fallo" te da un segundo filtro. No basta con saber que algo requiere acción humana; hay que saber con qué prisa y de quién. Un sistema que manda todo al mismo canal, con la misma urgencia, hace que lo crítico se confunda con lo que podía esperar.

Ejercicio 3 — Diseña la política de un workflow nuevo. Cumbre agrega un quinto workflow, send-invoice, que genera y envía la factura por correo cuando un pedido se surte. Aplica las tres preguntas de diseño: ¿qué es un fallo real para este workflow?, ¿quién responde?, ¿con qué urgencia? Considera especialmente qué pasa con el correo, recordando la lección 3.

Ver solución

¿Qué es un fallo real? Hay que separar tres casos. (1) La generación de la factura falla por un dato faltante: fallo real, el pedido se surtió pero no tiene factura. (2) El envío del correo da timeout y se recupera al reintentar: transitorio, solo log. (3) El envío falla de forma persistente —la dirección de correo es inválida, el servidor de correo está caído—: fallo real, la factura se generó pero no llegó al cliente.

¿Quién responde? Probablemente finanzas o administración, porque una factura es un documento fiscal y su ausencia tiene consecuencias contables.

¿Con qué urgencia? Media, en general. Una factura que no salió hoy puede salir mañana sin drama —a diferencia de un reembolso atascado, no hay dinero en movimiento—. Va a la cola de mensajes muertos como advertencia, para que finanzas reintente el envío o corrija el dato.

El detalle del correo, conectando con la lección 3: el correo es un efecto irreversible —una vez enviado, no se retira—. Por eso send-invoice debe ir al final del orden de efectos, cuando el pedido ya está surtido y confirmado. Si se enviara antes y el pedido después se cayera, tendrías que desmentir una factura, que es feo y confuso. Y si el mismo correo se enviara dos veces por un reintento sin idempotencia, el cliente recibiría dos facturas iguales —un duplicado que en un documento fiscal sí importa—, así que el envío necesita su clave de idempotencia como cualquier otro efecto.

Por qué funciona: este ejercicio junta las tres lecciones. La política de alertas (esta lección) decide que el fallo de envío es una advertencia de urgencia media para finanzas; el orden de efectos (lección 3) pone el correo al final por irreversible; y la idempotencia (Módulo 2, lección 2) evita la doble factura. Diseñar un workflow nuevo es, cada vez, aplicar todo el módulo junto.

Resumen y siguiente paso

En esta lección viste que la reacción humana al fallo empieza por una decisión: ¿esto es un detector de humo o un foco que parpadea? Distinguiste el fallo transitorio —que un reintento o una compensación cura solo, y que va a un log— del fallo terminal —que ningún mecanismo automático resuelve y que necesita a una persona—. Entendiste la fatiga de alertas y por qué menos alertas es más seguro que más: un canal saturado de tostadas quemadas entrena al equipo a ignorar la única alerta que importaba. Aplicaste las tres preguntas de diseño —qué es un fallo real, quién es el dueño, con qué urgencia— a los cuatro workflows de Cumbre, y sacaste una política que en un día normal produce cero o una alerta. Le pusiste niveles de severidad para que el canal comunique la urgencia por sí mismo. Y marcaste el límite: esta lección diseña la política de alertas —correctitud—, no el dashboard de observabilidad —operación, de la otra guía—.

Antes de avanzar deberías poder: clasificar un fallo cualquiera de tu sistema como transitorio o terminal; explicar qué es la fatiga de alertas y por qué "avísame de todo" la produce; y escribir, para un workflow, qué es un fallo real, quién responde y con qué urgencia.

Lo que no viste todavía es la maquinaria que ejecuta esta decisión. Definiste que un reembolso atascado debe alertar a finanzas y que un pedido mal formado debe guardarse sin perderse —pero ¿dónde vive el código que atrapa el fallo, decide su nivel, y actúa en consecuencia? La lección 5 lo construye: el nodo Error Trigger como error workflow central que captura cualquier fallo del sistema en un solo lugar, y la cola de mensajes muertos —una tabla dead_letter en el mismo Postgres del ledger— donde el item que falló tras todos los reintentos se aparta con su contexto completo, para que nada se pierda y todo se pueda reprocesar.

Recursos

• Error handling — n8n Docs — la base de cómo n8n detecta y enruta un fallo, que la lección 5 convierte en la maquinaria que ejecuta esta política de alertas.
• Error Trigger — n8n Docs — el nodo que captura el fallo y desde el cual decidirás, según lo diseñado aquí, si alertar o solo registrar.
• Handle errors gracefully — n8n Docs — guía oficial de diseño de manejo de errores, con el marco de decidir qué hacer ante cada tipo de fallo.