Qué se pierde exactamente cuando una automatización se cae (y por qué no es «nada»)
La primera pregunta después de una caída suele ser «¿ya funciona?». La segunda, la que casi nadie hace, es «¿qué pasó con lo que llegó mientras no funcionaba?». Y la respuesta depende de una cosa que se decidió el día que se montó el flujo: si lo que entra tiene una fuente consultable o si solo existió como un evento de paso.
Los dos casos se comportan de forma opuesta. Si tu flujo lee de un sitio que guarda —los pedidos de la tienda, los tickets del CRM, los correos de una bandeja—, no has perdido nada: el dato sigue ahí, esperando a que alguien lo procese. Si tu flujo depende de que alguien te empuje el dato —un webhook, una notificación— y el emisor no reintenta ni conserva histórico, ese evento se evaporó. No hay registro, no hay error y no hay pantalla donde buscarlo.
- Lo consultable se recupera. Pedidos, registros, documentos: todo lo que persiste en el origen se puede volver a pedir por rango de fechas y reprocesar.
- Lo empujado depende del emisor. Stripe, GitHub o Shopify reintentan sus webhooks durante horas o días; un script interno o una integración casera casi nunca. Antes de confiar en un webhook, comprueba si su emisor reintenta y durante cuánto.
- Lo que se procesó a medias es el caso peor. Un flujo que creó el registro pero se cayó antes de marcarlo como enviado deja el sistema en un estado que ni está hecho ni está pendiente. Es el que produce duplicados al reprocesar.
- Lo que se procesó mal en silencio no es una pérdida, es una corrupción. No lo arregla este plan; lo detecta la vigilancia de la que va detectar fallos en automatizaciones.
Esa distinción no es teórica: decide qué se puede prometer. Cuando alguien pregunta «¿se ha perdido algo?», la respuesta honesta es «de lo que entra por la tienda, no; de lo que entra por el webhook del proveedor X, depende de si reintenta». Y si nunca lo has comprobado, esa es la primera tarea, antes que cualquier reproceso.
Idempotencia primero: el arreglo que duplica facturas
Hay una tentación fortísima el día de la caída: coger el lote de las horas malas y volver a pasarlo entero. Es rápido, se siente resolutivo y es la forma más común de convertir un incidente pequeño en uno caro. Porque parte de ese lote sí se procesó —lo de los primeros minutos, lo que entró en los huecos en los que el servicio respondía— y ese trozo se va a ejecutar por segunda vez.
La pieza que lo impide se llama idempotencia y significa exactamente esto: ejecutar dos veces la misma operación deja el mismo resultado que ejecutarla una. No es un ajuste que se activa; es una propiedad que se diseña, y se sostiene sobre dos decisiones concretas.
- Una clave estable por unidad de trabajo. El número de pedido, el id del mensaje, el hash del documento. Nunca la marca de tiempo, nunca un contador de la ejecución, nunca «el registro más reciente»: eso cambia entre intentos y rompe la comparación.
- Un paso de escritura que comprueba antes de crear. Buscar por esa clave y, si existe, actualizar o salir sin hacer nada. Muchas APIs lo dan resuelto con una cabecera de clave de idempotencia o con un «crear o actualizar» nativo; cuando no la hay, se monta a mano con una tabla propia de claves ya procesadas.
Regla práctica que ahorra discusiones: si un flujo no es idempotente, no tiene plan de recuperación, tiene un plan de riesgo. Y el orden importa —hacerlo idempotente va antes de reprocesar nada, aunque el jefe esté mirando el reloj—. Reprocesar un flujo no idempotente para ganar veinte minutos y generar cuarenta facturas duplicadas es un mal negocio que además hay que explicar.
Reintentos con espera creciente: qué se reintenta y qué no se debe reintentar nunca
La mayoría de fallos no necesitan que nadie los recupere: se arreglan solos si el sistema espera un poco y vuelve a intentarlo. Un tiempo de espera agotado, un límite de peticiones, un 503 de un proveedor que está desplegando. La condición es que el reintento esté bien hecho, y «bien hecho» tiene una forma concreta.
Espera creciente: no reintentar cada segundo, sino separando los intentos cada vez más —unos segundos, después el doble, después el doble otra vez—, con un pequeño desfase aleatorio para que mil ejecuciones que fallaron a la vez no vuelvan todas a la vez. Reintentar en bucle inmediato contra un proveedor caído no lo ayuda a levantarse: lo mantiene en el suelo, y de paso consume tu cuota.
Y una distinción que separa los reintentos útiles de los dañinos: se reintenta lo que falló por el entorno, no lo que falló por el dato. Un 500 o un tiempo agotado son candidatos legítimos. Un 400 porque falta un campo obligatorio, un 401 por credencial caducada o un 422 porque el importe es negativo no mejoran por repetirse: eso va directo a la cola de fallidos, porque cada reintento es solo ruido y coste. Un flujo que reintenta cinco veces un error de validación gasta cinco veces y aprende cero.
Cuántos intentos: entre tres y cinco cubre prácticamente todo lo transitorio. A partir de ahí, la causa ya no es un hipo del entorno, y seguir insistiendo solo retrasa el momento en que una persona se entera. Ese momento —el paso de reintentar a rendirse— es lo que da sentido a la siguiente pieza.
La cola de fallidos: dónde va lo que no pudo pasar y cómo se relanza
Cuando se agotan los reintentos, el trabajo tiene que aterrizar en algún sitio. Si ese sitio no existe, aterriza en el log —es decir, en ninguna parte—. La cola de fallidos es ese sitio: una tabla, una hoja, un canal, lo que sea, siempre que guarde tres cosas por cada fallo.
- El dato original íntegro, no un resumen ni el mensaje de error. Sin la carga completa no puedes relanzar: solo puedes investigar.
- El motivo del fallo y el momento, para poder agrupar. Doscientos fallos con el mismo motivo son un problema; doscientos con motivos distintos son doscientos problemas.
- El estado: pendiente, relanzado, resuelto o descartado con razón. Sin estado, la cola se convierte en un cementerio que nadie se atreve a vaciar.
Lo que cambia al tenerla es la conversación. Se pasa de «se ha perdido lo de ayer» a «hay 214 en cola: 190 fallaron por el proveedor caído y se relanzan tal cual, 24 fallaron por validación y necesitan mirada». Eso es un incidente gestionable. Y añade una señal de salud que ninguna alerta da igual de bien: una cola que crece avisa de un problema sistémico antes de que lo haga un cliente.
El relanzado se hace en lotes pequeños y en orden, nunca todo de golpe. Primero un puñado, se comprueba el resultado en el destino, y solo entonces el resto. Si el primer lote falla igual, la causa no estaba resuelta y acabas de ahorrarte repetir el error doscientas veces. Todo esto asume lo del apartado anterior: sin idempotencia, relanzar una cola es apostar.
Reconciliación: cómo encuentras lo que nunca llegó a entrar
Reintentos y cola cubren lo que falló. Queda el agujero de verdad: lo que nunca llegó a intentarse. El webhook que se perdió, el disparador que estaba desactivado, el registro que el filtro descartó por un campo vacío. Ahí no hay error, no hay fallo en cola y no hay nada que reintentar. No hay ni rastro de que debiera haber pasado algo.
La única forma de encontrarlo es dejar de mirar la automatización y comparar los dos extremos. Eso es reconciliar: pedir al origen todo lo que cambió en una ventana de tiempo, pedir al destino lo que se creó en esa misma ventana, cruzar por la clave estable y quedarte con la diferencia. Lo que está en el origen y no en el destino es exactamente lo que se perdió.
Tres detalles que deciden si la reconciliación sirve o da falsos positivos: usa la misma clave estable de la idempotencia (si comparas por nombre de cliente o por importe, vas a encontrar diferencias que no existen); deja un margen de tiempo de unos minutos en los bordes de la ventana, porque el dato de origen y el de destino no se escriben en el mismo instante; y decide qué hace con la diferencia: lo prudente es que la mande a la cola de fallidos para relanzarla por el camino normal, no que la escriba directamente por una vía paralela que se salta las validaciones del flujo.
La cadencia depende del daño, no del volumen. Diaria y automática en lo que mueve dinero o compromisos con cliente; semanal en lo interno de bajo impacto. Y sobre todo permanente, no solo después de un susto: la reconciliación vale precisamente porque encuentra el pedido que se perdió un martes cualquiera sin que se cayera nada, ese que hoy se descubre cuando el cliente escribe preguntando. Es la misma disciplina de cuidado continuo que sostiene el mantenimiento de las automatizaciones con IA.
El plan de recuperación: quién lo ejecuta, en qué orden y con qué comprobación final
Las cuatro piezas anteriores son capacidades. Lo que las convierte en recuperación es un plan escrito de antemano, corto, que alguien pueda ejecutar el día malo sin improvisar y sin depender de que esté disponible la persona que montó el flujo. Cabe en media página y tiene seis pasos.
- 1. Parar la entrada. Antes de recuperar, cerrar el grifo: si el flujo sigue tragando mientras reprocesas, no sabrás nunca qué lote es cuál.
- 2. Fijar la ventana. Desde cuándo hasta cuándo estuvo mal. Con margen por los dos lados; sobra más de lo que falta.
- 3. Confirmar la idempotencia del flujo. Si no la tiene, se arregla aquí. No se salta este paso por prisa.
- 4. Reconciliar la ventana. Comparar origen y destino, y mandar la diferencia a la cola de fallidos.
- 5. Relanzar en lotes pequeños, comprobando el destino después del primero antes de seguir con el resto.
- 6. Cerrar con una comprobación de resultado, no de ejecución: contar registros en el destino y cuadrarlos con el origen. Que el reproceso «terminó sin errores» no demuestra nada.
Y una cosa que no es técnica pero decide el resultado: el plan necesita un dueño con nombre y apellidos, no un departamento. La misma regla que gobierna todo lo demás en gobernanza y control de la automatización: sin nombre no hay control, solo un documento. Si vas a montar el conjunto desde cero, el mapa completo está en la guía de automatizar con IA.
La conclusión incómoda es que la recuperación no se improvisa: se instala. Reintentos, idempotencia, cola y reconciliación se montan cuando todo va bien, porque el día que hace falta ya no hay tiempo de construirlas. Si tus flujos críticos no las tienen hoy, eso es exactamente lo que hacemos al dejar un proceso en producción en automatización de operaciones: no solo que funcione, sino que sepa recuperarse cuando no funcione.