Qué hacer cuando una automatización falla: registro de errores, alertas y recuperación

Cuando falla una automatización, no conviene relanzarla de inmediato. Primero hay que comprobar qué ejecución está afectada, localizar el primer punto en el que se produjo el error cuando la plataforma muestra el historial en secuencia y verificar si los pasos anteriores ya dejaron efectos en otros sistemas. Esta secuencia ayuda a evitar duplicados de pedidos, correos, documentos, movimientos de inventario u otras acciones.

Una automatización fiable no es la que se supone infalible, sino la que hace visible el error, avisa a la persona adecuada y permite recuperar el proceso con control.

Procedimiento en 7 pasos cuando falla una automatización

1. Identifica la ejecución afectada. Confirma el proceso, la hora y el identificador de ejecución disponible.
2. Contén el impacto. Si el flujo sigue generando acciones repetidas, errores o registros incompletos, pausa el proceso o limita temporalmente nuevas entradas si el diseño lo permite.
3. Localiza la primera acción fallida. Distingue la causa original de los fallos posteriores en cascada.
4. Comprueba qué efectos ya se produjeron. Revisa los sistemas de destino antes de repetir cualquier paso.
5. Clasifica el error. Decide si parece transitorio, de autenticación, permisos, datos, límite de uso o recurso inexistente.
6. Registra y alerta. Deja constancia del contexto necesario y avisa al responsable o canal compartido.
7. Recupera desde el punto adecuado. Reintenta, continúa desde el paso pendiente, reprocesa solo el elemento afectado o detén y escala el caso.

La forma concreta de aplicar estos pasos depende de la herramienta y del diseño del proceso. Historiales, alertas, reintentos, retención de registros y opciones de reejecución no son funciones universales de todas las plataformas.

Qué hacer en los primeros minutos tras detectar el fallo

1. Identifica el proceso y la ejecución afectados. Confirma el nombre de la automatización, la hora del fallo y el identificador de ejecución disponible en la plataforma o en el registro.
2. Valora el impacto inmediato. Prioriza los procesos que afectan a pedidos, pagos, facturación, existencias, atención al cliente o datos personales.
3. Contén el problema si sigue produciendo efectos. Si la automatización continúa creando errores, registros incompletos o acciones repetidas, puede ser necesario pausarla o impedir temporalmente nuevas entradas. La medida concreta dependerá de la herramienta y del diseño del proceso.
4. Comprueba el estado real de los sistemas implicados. No basta con ver que una ejecución aparece como fallida: revisa si el ERP, CRM, correo, API u otro sistema recibió parte de la operación.
5. No tomes la ausencia de una alerta como una confirmación de éxito. Las notificaciones pueden limitarse a ciertos tipos de fallo, agruparse, retrasarse o no llegar. Conviene revisar también el historial de ejecuciones o la monitorización centralizada.

Una causa habitual de fallo puede ser temporal, como una interrupción de red o la indisponibilidad momentánea de un servicio externo. También puede deberse a conexiones o credenciales caducadas, permisos modificados, límites de uso o cambios en una API. Por eso el diagnóstico debe preceder a cualquier reintento.

Localiza la primera acción que falló

En una ejecución con varios pasos, un fallo inicial puede provocar errores posteriores en cascada. Cuando la plataforma muestra las acciones en secuencia, empieza por la primera acción que figure como fallida y comprueba después el resultado en los sistemas de destino.

En Power Automate, la documentación diferencia los fallos en cascada de la causa original: las acciones posteriores pueden aparecer como fallidas aunque no se hayan ejecutado porque dependían de una acción anterior. Por ello, su historial de ejecuciones recomienda revisar la primera acción fallida.

Registra al menos esta información antes de modificar o relanzar el proceso:

• Nombre del flujo o proceso afectado.
• Fecha y hora del fallo.
• Identificador de ejecución.
• Etapa o acción que falló primero.
• Mensaje o código de error recibido.
• Sistema externo implicado.
• Estado conocido de los pasos anteriores y posteriores.

Con estos datos podrás separar la causa de sus consecuencias. Por ejemplo, un fallo de autenticación puede impedir una actualización en un ERP y hacer que después falle una notificación. La notificación no sería necesariamente el problema original.

Clasifica el fallo antes de decidir

Tipo de problema	Ejemplos habituales	Respuesta inicial prudente
Transitorio	Red inestable, servicio temporalmente no disponible, límite de tasa	Valorar un reintento limitado y progresivo.
Autenticación o conexión	Credenciales caducadas, conexión rota	Corregir la conexión y comprobar los efectos previos antes de reanudar.
Permisos	Acceso insuficiente a un recurso o acción	Detener, revisar permisos y escalar al responsable correspondiente.
Datos	Campo obligatorio ausente, formato inválido, dato duplicado	Corregir o revisar el dato antes de reprocesar.
Recurso inexistente	Registro eliminado, ruta o recurso ya no disponible	Investigar la causa y decidir cómo tratar el elemento afectado.

Los códigos HTTP, cuando existen, son solo una pista. Un 401, 403, 404, 429 o un error 5xx no debe convertirse en una regla automática sin revisar la respuesta concreta de la API, el conector y el contexto del proceso.

Crea un registro de errores útil, no solo un mensaje genérico

Un mensaje como “el flujo ha fallado” obliga a investigar desde cero. Un registro estructurado permite que operaciones o tecnología entiendan qué ocurrió y qué falta por hacer.

Para una pyme, no es obligatorio implantar una plataforma de observabilidad completa desde el principio. Puede bastar con un registro consistente que incluya:

• Momento del fallo: cuándo se produjo y, si es relevante, cuándo fue observado.
• Proceso y etapa: qué automatización se ejecutaba y en qué acción falló.
• Identificador de ejecución: para abrir el historial exacto.
• Error: mensaje, código y contexto técnico disponible.
• Sistema implicado: ERP, CRM, correo, API, base de datos u otro servicio.
• Estado posterior: detenido, pendiente de revisión, reintentado, recuperado o escalado.
• Identificadores de negocio: por ejemplo, referencia de pedido o cliente, solo si son necesarios para investigar y se gestionan de forma segura.

Plantilla mínima de registro o alerta

Esta plantilla es un ejemplo orientativo, no un caso real ni un formato obligatorio:

Campo	Qué debe indicar
Proceso	Nombre claro de la automatización afectada.
Ejecución	Identificador único o enlace al historial disponible.
Etapa	Primera acción fallida conocida.
Error	Mensaje, código y respuesta técnica relevante.
Sistema	Servicio o aplicación implicada.
Impacto	Consecuencia operativa conocida o posible.
Estado	Detenido, pendiente de revisión, reintentado o recuperado.
Siguiente acción	Revisar datos, renovar conexión, comprobar duplicados o escalar.

Cuando una ejecución atraviesa varios servicios, puede ser útil añadir un identificador de correlación o de traza. OpenTelemetry define campos como TraceId y SpanId para relacionar registros técnicos entre componentes; aquí se usan únicamente como referencia de diseño, no como requisito para implantar una automatización en una pyme.

El registro debe aportar contexto suficiente para investigar, pero no convertirse en un almacén de secretos o datos innecesarios.

Evita guardar contraseñas, tokens, credenciales, documentos completos o datos personales que no sean imprescindibles. Limita los accesos a los registros y aplica las políticas internas de seguridad y protección de datos que correspondan.

Diseña alertas que permitan actuar

Una alerta útil no se limita a avisar de que algo ha ido mal: indica qué proceso está afectado, cuál es el impacto y dónde revisar los detalles. Además, debe llegar a un responsable operativo o a un canal compartido, no únicamente a la persona que creó la automatización.

Para cada alerta, incluye:

• Nombre del proceso afectado.
• Hora del fallo.
• Identificador de ejecución.
• Etapa que falló primero.
• Mensaje o código de error.
• Sistema externo afectado.
• Nivel de impacto o prioridad interna.
• Enlace al historial de ejecución o al registro, cuando la plataforma lo permita.
• Acción inicial esperada: revisar, corregir datos, renovar conexión, pausar o escalar.

También es necesario definir quién revisa cada tipo de aviso, quién cubre a esa persona cuando no está disponible y qué plazo interno se considera razonable según la criticidad del proceso. En automatizaciones importantes, un buzón de equipo o un canal compartido reduce la dependencia de una única persona.

Prueba las alertas periódicamente y revisa el historial o la monitorización de forma independiente. En Power Automate, las alertas por ejecución solo se envían cuando el sistema identifica determinados problemas con una corrección conocida; los fallos generales y los fallos en cascada pueden no generar un correo individual. La documentación también indica un periodo de enfriamiento de 28 días entre alertas individuales repetidas del mismo flujo. Estas condiciones son específicas de Power Automate y pueden ser distintas en otras herramientas.

Decide si conviene reintentar o detener el proceso

Los reintentos automáticos son apropiados principalmente para errores transitorios: problemas temporales de red, indisponibilidad puntual de un servicio o límites de tasa. En estos casos, el backoff progresivo aumenta el tiempo entre intentos y reduce el riesgo de sobrecargar aún más el sistema afectado.

Un reintento debe tener un límite. Si un elemento falla siempre, repetirlo indefinidamente puede bloquear trabajo posterior, aumentar el consumo y ocultar la causa real.

Cuándo es razonable reintentar

• El servicio externo parece temporalmente no disponible.
• La respuesta indica un límite temporal de uso y la integración permite esperar.
• La operación es idempotente o existe una comprobación fiable para evitar duplicados.
• El proceso cuenta con un número máximo de intentos y una salida clara si no se recupera.

Cuándo conviene detener y pedir intervención

• Los datos de entrada son inválidos o incompletos.
• Faltan permisos o la autenticación ha dejado de ser válida.
• El recurso de destino ya no existe.
• No se puede confirmar si el intento anterior ya creó un efecto.
• La operación afecta a pagos, facturación, inventario, comunicaciones al cliente o datos personales y no hay una recuperación segura definida.

Cómo decidir límites de reintento y espera

No existe una configuración universal. Conviene decidirla según la criticidad del proceso, la ventana operativa disponible, el coste de duplicar una acción, los límites publicados por la API o el proveedor, el volumen de elementos procesados y la capacidad real del equipo para supervisar incidencias.

Un proceso de bajo impacto puede admitir una recuperación manual tras varios intentos limitados. En cambio, si una ejecución puede cobrar, emitir documentos, alterar existencias o enviar comunicaciones sensibles, el umbral para detener y pedir revisión humana debe ser más conservador.

Comprueba la idempotencia antes de reejecutar

La idempotencia significa, de forma práctica, que repetir una operación no debería producir un cambio adicional inconsistente en el estado del sistema. Debe estar garantizada por el diseño del proceso o por el sistema de destino; no debe suponerse solo porque una acción parezca repetible.

La idempotencia no garantiza por sí sola que no existan efectos externos, respuestas ambiguas, notificaciones duplicadas o efectos intermedios. Si no está claro si el sistema de destino recibió la operación, hay que comprobar el resultado antes de repetirla.

No des por hecho que una acción es segura de repetir. Crear un pedido, enviar un correo, emitir un documento, cobrar un importe o modificar existencias puede haber funcionado en el sistema de destino aunque la automatización no recibiera una respuesta final.

Antes de reejecutar, responde a estas preguntas:

1. ¿El paso anterior llegó a completarse en el sistema de destino?
2. ¿El dato original sigue siendo válido?
3. ¿Existe una clave de idempotencia, una referencia única o una consulta que permita comprobar si ya se creó el resultado?
4. ¿Se puede continuar desde el paso fallido en lugar de ejecutar todo el flujo?
5. Si no hay certeza, ¿debe revisar el caso una persona antes de continuar?

Si no es posible garantizar una reejecución segura, la revisión humana es preferible a automatizar un posible duplicado.

Recupera desde el punto adecuado

La mejor estrategia de recuperación depende de qué pasos se completaron y de si producen efectos secundarios. No siempre es correcto relanzar todo el proceso.

Estrategia	Cuándo puede encajar	Riesgo a controlar
Relanzar el proceso completo	Cuando los pasos son idempotentes o se comprueba que no dejaron efecto.	Duplicar registros, comunicaciones o actualizaciones.
Continuar desde el paso fallido	Cuando se conocen y verifican los pasos ya completados.	Perder contexto si no se conserva el estado necesario.
Reprocesar solo elementos fallidos	En procesos por lotes, si la plataforma o el diseño lo permiten.	Necesidad de identificar correctamente cada elemento afectado.
Aplicar una acción compensatoria	Cuando se debe deshacer un cambio anterior antes de recuperar.	La compensación puede no restaurar exactamente el estado previo.

En procesos distribuidos, el patrón saga describe conceptualmente dos posibilidades: continuar el flujo tras resolver el problema o ejecutar acciones compensatorias para contrarrestar cambios anteriores. No es una solución automática ni necesaria para toda automatización, pero sirve para diseñar procesos con varios sistemas y efectos relevantes.

En ejecuciones por lotes, si la plataforma lo permite, suele ser preferible identificar y reintentar únicamente los elementos fallidos. Repetir un lote completo por un único error puede reprocesar datos válidos innecesariamente.

Cuándo utilizar una cola de pendientes o de errores

Una cola de errores, también llamada dead-letter queue o DLQ, aparta los elementos que no se han podido procesar tras varios intentos. Así, un elemento problemático no bloquea indefinidamente el resto del trabajo.

Puede tener sentido en procesos asíncronos, con volumen relevante o con varias integraciones, pero no es un requisito para cualquier flujo sencillo. Para que sea útil necesita:

• Un límite claro de reintentos antes de enviar el elemento a la cola.
• Un responsable de revisar los elementos pendientes.
• Un periodo de retención acorde con la operativa y las políticas internas.
• Un procedimiento para corregir la causa y reprocesar de forma segura.
• Controles para evitar que un elemento que siempre falla vuelva a circular sin límite.

La cola no resuelve por sí sola el fallo. Solo conserva y separa el trabajo pendiente para que pueda tratarse sin perderlo ni bloquear otros mensajes.

Ejemplo hipotético: pedido, ERP y notificación

Imagina, como ejemplo hipotético, una automatización que recibe un pedido desde una web, crea o actualiza el registro en un ERP y después envía una notificación interna.

La ejecución aparece como fallida al enviar la notificación. Antes de relanzarla, el equipo debería:

1. Localizar la primera acción fallida conocida y guardar su identificador de ejecución.
2. Comprobar en el ERP si el pedido ya se creó o actualizó.
3. Registrar que el paso de ERP está completado y que la notificación quedó pendiente.
4. Enviar una alerta al canal compartido con el proceso, la referencia necesaria, el error y un enlace al historial.
5. Decidir si es seguro ejecutar solo la notificación pendiente.

Relanzar el flujo completo sin revisar el ERP podría duplicar el pedido o repetir una actualización. Si el proceso no permite continuar selectivamente, necesitará una comprobación previa, una clave única o una revisión humana antes de reejecutarlo.

Checklist para que el próximo fallo sea recuperable

• Asignar un propietario principal y un responsable alternativo del proceso.
• Conservar historial y registros durante un periodo coherente con la operativa y las políticas internas.
• Registrar proceso, ejecución, etapa, error, sistema afectado y estado posterior.
• Ocultar secretos y minimizar datos personales o comerciales en registros y alertas.
• Enviar avisos a un canal compartido cuando el proceso sea relevante.
• Probar que las alertas llegan y revisar el historial o la monitorización de forma independiente.
• Diferenciar errores transitorios de errores permanentes.
• Configurar límites de reintentos y espera progresiva cuando proceda.
• Comprobar la idempotencia antes de repetir acciones con efectos externos.
• Documentar cómo verificar efectos parciales y cómo reprocesar cada tipo de incidencia.
• Revisar el diseño con personal técnico cuando intervengan pagos, facturación, inventario o datos personales; cuando corresponda, implicar también a responsables de cumplimiento.

Cuándo basta una herramienta estándar y cuándo valorar una solución a medida

Una herramienta estándar puede ser suficiente si el proceso tiene pocas dependencias, ofrece historial de ejecuciones, alertas configurables, reintentos controlados y una recuperación sencilla que el equipo puede gestionar.

Puede ser necesario valorar una solución más adaptada cuando se requiere correlacionar eventos entre varios sistemas, aplicar permisos específicos, conservar trazabilidad ampliada, reanudar desde puntos concretos, tratar grandes volúmenes con colas de errores o controlar con precisión qué operaciones pueden repetirse.

La decisión no depende solo de la herramienta. Conviene evaluar el impacto del proceso, las integraciones implicadas, el volumen, la sensibilidad de los datos y la capacidad interna para mantener y responder ante incidencias.

¿Cómo proceder?

Ante una automatización fallida, el orden importa: contener el impacto, encontrar la primera acción que falló, comprobar qué efectos ya se produjeron y recuperar solo lo que sea seguro repetir. Registrar el contexto, alertar a responsables definidos y documentar el procedimiento convierte un fallo puntual en una incidencia gestionable.

Antes de añadir más reintentos o cambiar de plataforma, revisa si el proceso tiene responsables, trazabilidad, controles de duplicados y una forma clara de recuperar ejecuciones parciales.

Preguntas frecuentes

¿Debo reintentar siempre una automatización fallida?

No. Los reintentos encajan sobre todo con errores transitorios, como una caída temporal de red, indisponibilidad puntual de un servicio o ciertos límites de uso. Antes de reintentar, hay que comprobar si la operación es segura de repetir y si el primer intento pudo dejar efectos en el sistema de destino. Ante datos inválidos, permisos insuficientes, credenciales caducadas o recursos inexistentes, suele ser preferible corregir la causa y revisar el caso antes de continuar.

¿Cómo sé si una ejecución ya creó o modificó datos antes de fallar?

Revisa el historial de ejecución para identificar los pasos completados y consulta el sistema de destino mediante una referencia única, como un identificador de pedido o de registro. No debes deducir que una acción no se completó solo porque la automatización terminó con error: puede haber fallado al recibir la respuesta o en un paso posterior.

¿Qué información debe contener una alerta de automatización?

Como mínimo, debe indicar el nombre del proceso, la hora, el identificador de ejecución, la primera etapa fallida conocida, el mensaje o código de error, el sistema afectado, el impacto y un enlace al historial o al registro cuando sea posible. También conviene indicar quién debe revisarla y cuál es la acción inicial esperada.

¿Qué diferencia hay entre reintentar todo el proceso y continuar desde el paso fallido?

Reintentar todo el proceso vuelve a ejecutar también los pasos anteriores, por lo que puede duplicar efectos si esos pasos ya se completaron. Continuar desde el paso fallido intenta preservar lo ya realizado y ejecutar solo lo pendiente, pero exige que el proceso conserve estado y que se haya verificado qué acciones tuvieron efecto.

¿Cuándo tiene sentido usar una cola de errores o dead-letter queue?

Tiene sentido en procesos asíncronos, con mayor volumen o criticidad, cuando algunos elementos pueden fallar repetidamente y no deben bloquear al resto. La cola debe incluir límites de reintentos, responsables, retención definida y un procedimiento seguro para revisar, corregir y reprocesar los elementos pendientes.