Historial de interrupciones de Uipath

1. 26 de octubre de 2026 a las 14:04 UTCidentified

   Actualmente estamos investigando una cuestión que repercute en la disponibilidad de información y servicios de operaciones de automatización. Nuestro equipo está evaluando activamente la situación para identificar la causa subyacente y determinar los pasos necesarios para restaurar las operaciones normales. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 26 de octubre de 2026 a las 15:35 UTCidentified

   Se ha resuelto el problema con las opciones de automatización. Actualmente estamos esperando que se mitigue la cuestión del servicio Insights. Se compartirán más actualizaciones cuando estén disponibles.

3. 26 de octubre de 2026 a las 17:09 UTCidentified

   Servicio de Insights en Singapur, Japón, Suiza, Canadá, India, Reino Unido, Europa, Estados Unidos, EAU, región de Corea del Sur y Australia está fijada en otras regiones

4. 26 de octubre de 2026 a las 18:27 UTCresolved

   La cuestión se ha resuelto y todos los servicios funcionan normalmente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de octubre de 2026 a las 21:35 UTCresolved

   Entre 20:42 y 21:19 UTC el 23 de octubre, algunos clientes de Orchestrator en Europa vieron respuestas lentas y errores intermitentes. Esto incluyó llamadas de robot para obtener activos, procesar artículos de cola y reportar estado de trabajo. Algunos empleos no atendidos pueden haber fracasado durante este tiempo. La causa fue un aumento repentino de la carga que alcanzó los límites de recursos de la base de datos. Añadimos capacidad de base de datos, y el rendimiento ha vuelto a la normalidad desde 21:19 UTC. Los clientes cuyo trabajo falló en esta ventana pueden necesitar reiniciarlos.

Traducido automáticamente desde la actualización oficial del incidente.

1. 22 de octubre de 2026 a las 12:59 UTCinvestigating

   Hemos identificado un problema que afecta a la IXP para clientes acogidos en la región de Australia. Desde 10:24 UTC, las solicitudes que utilizan el modelo Gemini 2.5 Flash están fallando en la región. Otros modelos no se ven afectados. Los datos de los clientes siguen siendo procesados únicamente en Australia. Estamos trabajando con Google para restaurar el servicio

2. 22 de octubre de 2026 a las 14:19 UTCmonitoring

   Se ha desplegado una solución y el servicio se está recuperando. Estamos monitoreando el sistema para asegurar la recuperación completa. Pronto se compartirán más actualizaciones

3. 22 de octubre de 2026 a las 14:33 UTCinvestigating

   Tras la recuperación inicial, el servicio se ha degradado de nuevo. Estamos investigando y trabajando para una resolución. Proporcionaremos más actualizaciones a medida que estén disponibles.

4. 22 de octubre de 2026 a las 15:42 UTCinvestigating

   Hemos contactado con Google Support, y han comenzado a investigar en su extremo. Mantendremos el monitoreo y compartiremos las actualizaciones como las tenemos.

5. 22 de octubre de 2026 a las 17:56 UTCmonitoring

   Estamos observando mejoras en el tráfico flash Gemini 2.5. Estamos monitoreando una posible solución de Google.

6. 22 de octubre de 2026 a las 21:02 UTCresolved

   El problema se resuelve de Google.

7. 26 de octubre de 2026 a las 3:20 UTCpostmortem

   ## Impacto del cliente Entre el 22 de octubre de 2026 a las 10:24 am UTC y el 22 de octubre de 2026 a las 6:04 pm UTC, solicitudes de procesamiento de documentos que utilizaron Gemini 2.5 Flash en la región de Australia fallaron con errores de capacidad. El impacto duró aproximadamente 7 horas y 40 minutos. Se afectó un subconjunto de clientes que utilizaban flujos de trabajo de extracción de documentos en esa región. Durante un intento de retroceso temporal en el registro, algunas solicitudes de extracción se recuperaron brevemente, pero la atribución de nivel de palabras y el texto de página generado fueron degradados hasta que el retroceso también comenzó a fracasar. ## Root cause La causa raíz fue una perturbación de la red regional del lado proveedor durante el mantenimiento simultáneo. Esto causó una fuerte oscilación de ancho de banda en el entorno de servicio de modelos del proveedor, lo que impidió que los sistemas de backend cargaran los datos modelo necesarios para atender las solicitudes Gemini 2.5 Flash y Gemini 3.5 Flash fiablemente en la región afectada. ## Detection El problema se detectó mediante alerta automatizada que identificó errores de limitación de tarifas en Gemini 2.5 Flash en la región de Australia. Nuestro equipo de ingeniería confirmó a través de la telemetría que las solicitudes afectadas fallaban constantemente y comenzó a coordinar una respuesta. ## Response A las 1:40 pm UTC, enrutamos el tráfico Gémini 2.5 Flash a Gemini 3.5 Flash dentro de la misma región para preservar la residencia de datos. La telemetría inicial no mostró errores de capacidad después de ese cambio, pero a las 2:10 pm UTC, Gemini 3.5 Flash también estaba devolviendo errores de capacidad, por lo que el inconveniente ya no era viable. A las 2:05 pm UTC, ajustamos las trayectorias de procesamiento de documentos relacionadas para que la atribución y la generación de texto de página utilizaran la misma caída en el registro; ese ajuste completó aproximadamente a las 2:09 pm UTC. Después de que el retroceso también falló, revertimos el cambio de enrutamiento, y por 4:28 pm el tráfico UTC estaba de vuelta en el camino esperado Gemini 2.5 Flash. A las 5:38 pm UTC, la telemetría mostró mejorar las tasas de éxito de Gemini 2.5 Flash. A partir de las 6:04 pm UTC en adelante, no se observaron más errores de capacidad, y las solicitudes posteriores tuvieron éxito. ## Follow up 1. Completar la evaluación de la capacidad modelo reservada para la región afectada utilizando los patrones de tráfico observados 2. Evaluar el comportamiento de reingreso y retroceso en los clientes de procesamiento de documentos para reducir la amplificación de reingreso durante fallos de capacidad del proveedor.

Traducido automáticamente desde la actualización oficial del incidente.

1. 15 de octubre de 2026 a las 12:27 UTCinvestigating

   Desde aproximadamente 11:17 UTC, los clientes de varias regiones han experimentado problemas con UiPath Agents and Solutions Management. Los nuevos empleos pueden permanecer en estado de espera, y los agentes en funcionamiento pueden experimentar retrasos al procesar escalaciones o esperar resultados de herramientas. Estamos investigando el tema y trabajando para una resolución.

2. 15 de octubre de 2026 a las 13:04 UTCmonitoring

   La cuestión ha sido mitigada. Estamos monitoreando los servicios afectados en todas las regiones para garantizar la estabilidad y confirmar que las salidas de empleo y las implementaciones de soluciones funcionan normalmente.

3. 15 de octubre de 2026 a las 13:22 UTCresolved

   Este incidente ha sido resuelto. Entre las 11:15 y las 12:45 UTC el 15 de octubre, un problema de configuración interna impidió que algunos eventos fueran entregados entre los servicios de UiPath en varias regiones. El problema se resolvió revolviendo el cambio, y la nueva actividad se está procesando normalmente. Algunos trabajos iniciados o en curso durante esta ventana pueden requerir atención: - Agentes: Los agentes que esperan en las tareas del Centro de Acción o los resultados de la herramienta de automatización pueden permanecer atrapados. Los trabajos iniciados por Orchestrator también pueden aparecer atascados o fuera de tiempo. - Maestro: Los procesos que esperan las tareas del usuario pueden no haberse reanudado después de la terminación de la tarea. - Aplicaciones: Los estados del artículo de la cola pueden ser obsoletos, y las acciones activadas por la terminación del artículo de la cola pueden no haber funcionado. - Autopilot para todos: Las conversaciones que esperan resultados de automatización pueden permanecer estancadas. - Entendimiento de documentos y fundamentación de contexto: Las automatizaciones y agentes que esperan la extracción, validación o indexación pueden permanecer suspendidas. - Servicio de Integración: Los eventos de conexión pueden no haber desencadenado los procesos o notificaciones previstos. - Soluciones y Studio Web: Solution instala, desinstala, publica, implementa y validaciones iniciadas durante esta ventana puede haber fallado o cedido. El reingreso de estas operaciones puede resolver la cuestión. Nos disculpamos por la interrupción y gracias por su paciencia.

4. 21 de octubre de 2026 a las 6:47 UTCpostmortem

   ** Impacto del cliente** El 15 de octubre de 2026, de 11:15 a 12:50 UTC (aproximadamente 1 hora y 35 minutos), algunos eventos intercambiados entre los servicios de nube UiPath no fueron entregados. Los clientes de todas las regiones de la nube comercial fueron afectados. Durante esta ventana: - Los nuevos agentes podrían quedarse en estado de espera. Los agentes que corren esperando un resultado de la herramienta, una escalada humana, extracción de documentos o terreno de contexto podrían no reanudarse. - Agentes conversacionales y Autopilot para Todos las conversaciones que iniciaron una automatización podrían no haber recibido su resultado. - Las instancias del proceso maestro que esperan una tarea de usuario podrían no haber avanzado después de que se completó la tarea, y los procesos desencadenados por los eventos del conector del Servicio de Integración podrían no haber comenzado. - Las aplicaciones que muestran o reaccionan al estado del artículo de la cola pueden mostrar información obsoleta. - Solución instala, desinstala, publica y las implementaciones pueden fallar o perder tiempo. - Algunos cambios de usuario, grupo y carpeta hechos en la ventana podrían no haberse propagado a todos los servicios. El trabajo comenzó después de 12:50 UTC no fue afectado. Robot ejecución de trabajo, colas y disparadores manejados dentro de Orchestrator siguió trabajando normalmente. *Causa de raíz* Estábamos moviendo la entrega de configuración de servicio interno a un nuevo mecanismo, un cambio destinado a no tener ningún efecto en los clientes. Cuando este cambio se aplicó al servicio de entrega de eventos, la configuración que produjo faltaba un valor requerido. Sin ella, el servicio trató varias integraciones de productos como apagado y silenciosamente dejó de entregar sus eventos. Debido a que el cambio llegó a todas las regiones de producción al mismo tiempo, cada región fue afectada. **Detección** El problema se detectó a las 11:51 UTC, aproximadamente 35 minutos después de que se iniciara el impacto, cuando se alertaba sobre los empleos de agentes que quedaban en el estado pendiente. Reports of solution deployments timing out followed, and an incident was declared at 12:12 UTC. **Response** Después de la primera detección a las 11:51 UTC, se identificó el cambio de configuración y se inició un rollback a las 12:00 UTC. Un retroceso inicial a las 12:14 UTC no restauró completamente la entrega. Luego el equipo detuvo el nuevo proceso de entrega de configuración y restauró la configuración anterior. La entrega del evento comenzó a recuperarse a las 12:40 UTC, y la recuperación completa en todas las regiones fue confirmada a las 12:50 UTC. Cuando sea posible, repetimos eventos perdidos para que el trabajo afectado pueda continuar. # Sigue # 1. El nuevo proceso de entrega de configuración se ha pausado para el servicio afectado y se mantendrá pausado hasta que la configuración se genere correctamente. 2. Validar la configuración producida por el nuevo mecanismo de entrega para los valores requeridos antes de que se aplique a cualquier entorno. 3. Realizar cambios en la ejecución de la configuración progresivamente en todas las regiones en lugar de en todas las regiones inmediatamente. 4. Mejorar nuestro monitoreo para detectar en minutos cuando los eventos dejan de ser entregados a una integración de productos que normalmente los recibe. 5. Mejorar nuestra capacidad de recuperar y volver a entregar los eventos perdidos durante una perturbación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 15 de octubre de 2026 a las 12:03 UTCresolved

   Algunos clientes de la región de Estados Unidos experimentaron retrasos en la ingestión de registros de robots, con mayor actividad observada entre aproximadamente 11:20 y 11:45 UTC. La cuestión se ha resuelto y la ingestión de registros ha vuelto a la normalidad. Gracias por su paciencia.

2. 22 de octubre de 2026 a las 10:13 UTCpostmortem

   ## Impacto del cliente Entre aproximadamente el 15 de octubre de 2026 a las 11:20 pm UTC y aproximadamente el 15 de octubre de 2026 a las 11:45 pm UTC, algunos clientes en la región del Este de Estados Unidos experimentaron retrasos en la ingestión de registro de robots en UiPath Orchestrator. Los registros de robot no estaban actualizados durante el período afectado. El impacto duró aproximadamente 20 minutos. ## Root cause Durante el incidente, se observó que 2 de las 13 instancias de servicio que manejaban la ingestión de registro de robots no se conectaban al servicio de ingestión de eventos. Sólo faltaban solicitudes al servicio de ingestión de eventos, y sólo en esos dos casos. Esto causó algunas solicitudes de ingestión de registros de robots para no completar con éxito, lo que dio lugar a datos de registro retardados para los clientes afectados. Durante el incidente no se determinó la causa fundamental de por qué sólo esos dos casos perdieron la conectividad al servicio de ingestión de eventos. El equipo se comprometió a realizar un examen posterior al incidente de los registros de los casos afectados para determinar la causa subyacente. Creemos que es un problema de infraestructura no reportado de nuestro proveedor de nube. ## Detection El problema se detectó a través de una alerta automatizada a aproximadamente 11:33 pm UTC el 15 de octubre de 2026, y se confirmó mediante telemetría mostrando excepciones de las dos instancias de servicio afectadas. ## Response Después de la detección, la telemetría confirmó que sólo dos instancias de servicio estaban generando excepciones. Los encuestados retiraron esos dos casos poco saludables del servicio, y los casos de sustitución comenzaron automáticamente. En aproximadamente 20 minutos de la primera alerta —aproximadamente a las 11:53 pm UTC— la telemetría indicó que estaban pasando comprobaciones de recuperación y monitoreo sintético. Se consideró un reinicio más amplio de todas las instancias de servicio, pero no se realizó, ya que el equipo determinó que no debía proceder sin entender primero la causa raíz. ## Follow up 1. Una revisión posterior al incidente de los registros de los casos de servicios afectados reveló que el problema era la infraestructura relacionada, y estamos siguiendo con el proveedor de infraestructura de la nube para más detalles. 2. Se publicará una actualización si la investigación produce nuevas conclusiones.

Traducido automáticamente desde la actualización oficial del incidente.

1. 14 de octubre de 2026 a las 7:26 UTCmonitoring

   Comenzando con 6:50 UTC hemos experimentado un outage global que ha afectado la carga de aplicaciones y aplicaciones codificadas todas las regiones excepto para India y Reino Unido. Se han resuelto los gastos y los servicios están en pleno funcionamiento. Impacto: No hay impacto continuo del usuario.

2. 14 de octubre de 2026 a las 7:43 UTCresolved

   Comenzando con 6:50 UTC hemos experimentado un outage global que ha afectado la carga de aplicaciones y aplicaciones codificadas todas las regiones excepto para India y Reino Unido. Se han resuelto los gastos y los servicios están en pleno funcionamiento. Impacto: No hay impacto continuo del usuario.

3. 23 de octubre de 2026 a las 12:08 UTCpostmortem

   ## Impacto del cliente Entre las 06:38 UTC y 07:21 UTC el 14 de octubre de 2026, una parte de las solicitudes de UiPath, aplicaciones de Coded y soluciones que dependen de ellas fracasaron en once regiones: Europa, Estados Unidos, Comunidad, Japón, Singapur, Australia, Canadá, Corea del Sur, Suiza, Emiratos Árabes Unidos y el entorno estadounidense retrasado. Las regiones de la India y el Reino Unido no se vieron afectadas. Alrededor del 2 por ciento de las solicitudes fallaron en general, entre 0,6 y 5 por ciento dependiendo de la región. Los usuarios afectados vieron que las aplicaciones no se cargan, solicitudes devuelven errores del servidor o respuestas lentas. En regiones donde las cápsulas de servicio tenían que ser reiniciadas, las aplicaciones eran inalcanzables hasta unos ocho minutos. Los tiempos de respuesta volvieron a la normalidad en cada región para 07:40 UTC. La mayoría de los usuarios de aplicaciones ya publicadas notaron poco o nada. Las definiciones de aplicaciones están caché en el navegador por hasta 24 horas, los datos de la aplicación provienen de Data Service y Orchestrator en lugar de esta base de datos, y el servicio siguió utilizando las conexiones de la base de datos que ya tenía. Las solicitudes que fallaron fueron aquellas que necesitaban una nueva conexión de base de datos: abrir el diseñador o la lista de aplicaciones, cargar una aplicación que aún no caché, descargar documentos e imágenes almacenadas en aplicaciones, y guardar o publicar. ## Root cause A las 06:38 UTC, mientras se estaba estableciendo el acceso a la base de datos para un nuevo despliegue regional, se cambió la contraseña del usuario de la base de datos que utiliza el servicio de aplicaciones. Ese usuario es compartido por los grupos de bases de datos de producción de todas las regiones afectadas, por lo que el cambio se aplica a todas ellas inmediatamente. Los servicios de funcionamiento siguen teniendo la contraseña anterior y ya no pueden abrir nuevas conexiones de bases de datos. Las regiones de la India y el Reino Unido no utilizan esta credencial y no se vieron afectadas. El cambio estaba destinado a crear un usuario independiente de bases de datos para la nueva región. En cambio, se cambió la contraseña del usuario existente que comparten todas las regiones. Nuestro proceso de cambio para las credenciales de la base de datos no separa claramente la creación de una nueva credencial de modificar una existente, y no requiere un cheque de cuántos grupos y regiones un cambio credencial afectaría. Combinado con un único usuario de base de datos que se comparte en regiones, esto permitió un cambio destinado a una región para causar un desembolso multiregión. ## Detection Nuestro monitoreo interno levantó la primera alerta a las 06:41 UTC, tres minutos después de los primeros fracasos, y alertas para cada región afectada seguido por 06:46 UTC. At 06:50 UTC the on-call engineer confirmed that every production cluster was being refused by its database and started the incident process. ## Response A las 07:05 UTC la contraseña anterior fue restaurada y los fallos de autenticación se detuvieron en todas partes. La mayoría de las regiones se reconectaron automáticamente. En las regiones que no lo hicieron, las cápsulas de servicio fueron reiniciadas o redistribuidas: Delayed US at 07:21 UTC and Switzerland by 07:30 UTC. Los fallos solicitados se detuvieron a las 07:21 UTC, los tiempos de respuesta volvieron a la base de referencia para las 07:40 UTC, y continuamos monitoreando hasta que el incidente se resolvió a las 07:43 UTC. ## Follow up Para evitar que esto suceda de nuevo, somos: - Introduciendo un procedimiento definido para crear y rotar las credenciales de la base de datos, con un examen previo al cambio que indica qué grupos y regiones comparten la credencial, y un despliegue escalonado que se verifica en una región antes de que se aplique más ampliamente. - Moverse para separar a los usuarios de bases de datos menos privilegiados de cada región, para que un cambio en una región no pueda afectar a otra. - Declarar automáticamente un incidente y paging a los propietarios de bases de datos cuando se detecta el mismo error de base de datos en varias regiones a la vez, en lugar de depender de la escalada manual de alertas regionales individuales. - Permitir a los servicios recoger las credenciales actualizadas de la base de datos sin reiniciar, y volver a conectar más rápido después de un fallo de autenticación.

Traducido automáticamente desde la actualización oficial del incidente.

1. 13 de octubre de 2026 a las 14:03 UTCinvestigating

   Actualmente estamos investigando un outage que afecta los servicios de UiPath Cloud en varias regiones. Los usuarios no pueden acceder a los servicios alojados en las regiones afectadas. Siguiente actualización: Se compartirá información adicional cuando esté disponible.

2. 13 de octubre de 2026 a las 14:37 UTCinvestigating

   Seguimos investigando esta cuestión.

3. 13 de octubre de 2026 a las 14:42 UTCinvestigating

   Se ha aplicado una solución y estamos monitoreando los resultados. El tema se limitó a Entendimiento de Documentos, Visión Computadora, Proxy Semántico, Autopilot Studi, IXP. Compartiremos otra actualización una vez que los servicios se hayan recuperado completamente.

4. 13 de octubre de 2026 a las 15:10 UTCinvestigating

   Se ha aplicado una solución y estamos monitoreando los resultados.

5. 13 de octubre de 2026 a las 15:19 UTCresolved

   Este incidente se ha resuelto tras la renovación del certificado SSL expirado que afectó a varios servicios dependientes de ML, incluyendo IXP, Entendimiento de Documentos, Visión de Computación, Proxy Semántico y Autopilot para Desarrolladores. La recuperación de los servicios ha progresado en todas las regiones afectadas, y se han configurado alertas automatizadas para ayudar a detectar con antelación la expiración de certificados y evitar interrupciones similares en el futuro. Gracias por su paciencia y comprensión.

6. 26 de octubre de 2026 a las 3:17 UTCpostmortem

   ## Impacto del cliente Entre 13:37 y 14:40 UTC el 13 de octubre de 2026, los clientes de varias regiones no pudieron utilizar documentos no estructurados IXP, minería de comunicaciones IXP y comprensión de documentos. Computer Vision y Autopilot para Desarrolladores características que dependen de los mismos servicios de aprendizaje automático también fallaron. Los clientes afectados vieron que las solicitudes fallaron con las respuestas "500 Error de Servidor Interno" o el tiempo fuera, los proyectos IXP que no se abrirían, y las actividades de Computer Vision fracasaron en las automatizaciónes de ejecución. El servicio se interrumpió durante aproximadamente 1 hora. No se perdieron datos de clientes. ## Root Cause The incident was caused by an expired security certificate used to establish secure connections to these services. El certificado es renovado por un proceso automatizado. Ese proceso ya no se ejecutó con éxito y los fallos no elevaron una alerta, por lo que el certificado no fue reemplazado antes de expirar. Las conexiones seguras con los servicios afectados fueron rechazadas de 13:37 UTC. ## Detection La vigilancia automatizada comenzó a alertar sobre errores y tráfico desaparecido a las 13:40 UTC, y el incidente fue declarado a las 13:54 UTC. El certificado vencido fue identificado a las 14:00 UTC, y la primera actualización de la página de estado fue publicada a las 14:03 UTC. Ninguna alerta advirtió que el certificado se acercaba a la expiración, y los repetidos fracasos de la renovación automatizada no se reportaron al equipo de propiedad, por lo que el problema sólo se detectó una vez que los clientes fueron afectados. ## Response A las 14:06 UTC el equipo confirmó que el certificado había expirado porque la renovación automatizada había estado fallando. A las 14:18 UTC se emitió una nueva credencial para el proceso de renovación. La renovación se inició manualmente a las 14:19 UTC y se completó a las 14:33 UTC, y para las 14:37 UTC cada punto final orientado al cliente había sido verificado para servir el certificado renovado. El tráfico volvió a niveles normales en aproximadamente 14:40 UTC. Después de un período de vigilancia, el incidente se resolvió a las 15:19 UTC. ## Follow-Up Para ayudar a prevenir incidentes similares en el futuro, estamos haciendo las siguientes mejoras: - Alerta bien antes de cualquiera de estos certificados que se acercan a la expiración. - Notificar al equipo de propiedad cuando la renovación automatizada falla. - Agregue cheques que alertan tan pronto como fallan las conexiones seguras a estos servicios. - Fortalecer la propiedad del proceso de renovación de certificados y las credenciales en las que se basa.

Traducido automáticamente desde la actualización oficial del incidente.

1. 13 de octubre de 2026 a las 10:32 UTCinvestigating

   Estamos investigando un problema donde los registros de ejecución de robots no aparecen en Orchestrator. estamos trabajando para determinar el alcance completo y la causa raíz.

2. 13 de octubre de 2026 a las 10:57 UTCresolved

   Esta cuestión se ha resuelto. Los registros de ejecución de robot están sincronizando y son visibles en Orchestrator de nuevo para Japón Orchestrator. Gracias por su paciencia.

3. 22 de octubre de 2026 a las 13:25 UTCpostmortem

   ## Impacto del cliente Entre las 07:00 UTC el 9 de octubre de 2026 y 10:45 UTC el 13 de octubre de 2026, alrededor del 6% de las entradas de registro de robots para clientes en la región de Japón no aparecieron en Orchestrator. La ejecución de empleo y todas las demás funcionalidades de Orchestrator no se vieron afectadas. Las entradas perdidas se hicieron visibles en Orchestrator después de que el problema fuera fijo. ## Root cause Los registros de robot se colocan en una cola dividida en 32 particiones, y un servicio de ingestión lee cada partición y almacena los registros para Orchestrator. El 9 de octubre, el servicio de ingestión en la región de Japón dejó de leer de 2 de las 32 particiones sin informar de un error. Los registros de esas particiones se guardaban en la cola pero no se almacenaban, por lo que no aparecían en Orchestrator. Nuestro monitoreo comprobó el servicio en su conjunto, no cada partición, por lo que el problema no fue detectado automáticamente. ## Detection El problema se detectó a través de informes de clientes. Declaramos un incidente a las 10:13 UTC el 13 de octubre y publicamos una notificación de la página de estado a las 10:32 UTC. ## Response Reanudamos el servicio de ingestión a aproximadamente 10:41 UTC, y reanudó la lectura de todas las particiones. Los registros mantenidos en la cola fueron procesados y se hicieron visibles en Orchestrator. El incidente se resolvió a las 10:57 UTC. ## Follow up * Estamos agregando monitoreo que nos alerta cuando cualquier partición deja de ser leída, por lo que este tipo de problema se detecta en minutos.

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de octubre de 2026 a las 21:34 UTCinvestigating

   Estamos investigando informes de un outage que impacta las fallas de creación de tareas HITL para Maestro en Estados Unidos. Impacto: Los usuarios pueden ser incapaces de crear tareas HITL. Siguiente actualización: Nuestros equipos están trabajando para entender la causa y el alcance y compartirán las actualizaciones como están disponibles.

2. 8 de octubre de 2026 a las 1:30 UTCidentified

   Hemos identificado la causa de un outage que impacta la creación de tareas HITL para Maestro en Estados Unidos y estamos trabajando para mitigar el problema. Impacto: Los usuarios pueden ser incapaces de crear tareas HITL. Siguiente actualización: Nuestros equipos están trabajando para mitigar el problema y compartirán las actualizaciones como están disponibles.

3. 8 de octubre de 2026 a las 3:28 UTCmonitoring

   Estamos preparando una solución para un outage impactando la creación de tareas HITL para Maestros con cronogramas SLA de tareas HITL configurados en EE.UU. y están trabajando para mitigar el problema. Impacto: Los usuarios pueden ser incapaces de crear tareas HITL dentro de Maestros con cronogramas SLA de tarea HITL configurados. Siguiente actualización: Nuestros equipos están trabajando para mitigar el problema y compartirán las actualizaciones como están disponibles.

4. 8 de octubre de 2026 a las 4:29 UTCresolved

   La solución para el problema que impacta la creación de tareas HITL para Maestro con los temporizadores SLA de tarea HITL configurados en EE.UU. ha sido completamente lanzado. La creación de tareas HITL ha vuelto a la normalidad.

5. 26 de octubre de 2026 a las 3:16 UTCpostmortem

   ## Impacto del cliente On 2026-10-05 between 9.30 PM UTC - 2026-10-07 3.30 UTC, Maestro BPMN y clientes de Case usando nodos HITL configurados Task Timer vieron fallas de su depuración y casos de producción en la etapa HITL, con 4xx. Se identificaron alrededor de 30 casos de este tipo a través de clientes de EE.UU. y Europa, que fueron bloqueados sin ninguna solución. ## Root cause La configuración de una tarea SLA requiere un objeto que incluya los criterios de inicio y finalización, el temporizador del SLA y el resultado de la violación del SLA. Los clientes configuran eso en el diseñador maestro en el nodo HITL. El resultado se mantuvo erróneamente no obligatorio en la superficie de diseño, aunque una configuración SLA sin un resultado no se persistió y no tiene sentido empresarial. El equipo de backend del Centro de Acción había añadido una validación para lanzar una mala solicitud (400) en caso de un objeto SLA no nulo con un resultado perdido. Esto terminó afectando a los clientes que habían añadido los criterios Start/End en el nodo pero no configurado un resultado. Los casos que se estaban ejecutando anteriormente fallaron con 400, y no pudieron reanudar ## Detection Un cliente informó el problema al Maestro Engineering SME, quien lo planteó internamente con el equipo. El equipo Maestro investigó este fracaso, y observó un número creciente de fracasos para la USI, y algunos otros inquilinos a través de registros, lo que los llevó a involucrar al equipo del Centro de Acción. ## Response El equipo Maestro recibió el informe del cliente a través de Email, e hizo una investigación inicial e identificó una posible regresión, después de lo cual, se comprometió el Centro de Acción PyME, el tema reproducido en entornos más bajos, un rebote de la característica aplicada y probada, y lanzado a todas las regiones afectadas. Se resolvió con todas las instancias que se estaban retratando y reanudando internamente. ## Follow up 1. Agregue validación para este escenario en todas las superficies de base cruzada del servicio para garantizar la revisión humana 2. Agregue las pruebas de seguimiento e integración necesarias para detectar esta cuestión más rápido

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de octubre de 2026 a las 17:37 UTCinvestigating

   Estamos investigando informes de lentitud intermitente y errores que afectan a un subconjunto de organizaciones en la región de Estados Unidos Oriental de Automation Cloud. Los usuarios afectados pueden ver páginas en el Orchestrator UI no se cargan (por ejemplo, la página Jobs que devuelve "Se ha producido un error"), y las operaciones de robot como las transacciones de cola y la sesión comienzan pueden darse un tiempo intermitente. Proporcionaremos una actualización tan pronto como esté disponible más información.

2. 7 de octubre de 2026 a las 18:13 UTCmonitoring

   Hemos aplicado un aumento de la capacidad a la infraestructura de base de datos afectada en la región de Estados Unidos Oriental y las tasas de error y latencia retornan a niveles normales. Proporcionaremos una actualización tan pronto como esté disponible más información.

3. 7 de octubre de 2026 a las 19:06 UTCresolved

   Tenemos el problema en la región de Estados Unidos Oriental y las tasas de error y latencia retornan a niveles normales.

4. 14 de octubre de 2026 a las 11:42 UTCpostmortem

   ## Impacto del cliente Entre las 13:00 UTC y las 18:15 UTC el 7 de octubre de 2026, los clientes de la región de Estados Unidos experimentaron errores intermitentes y respuestas lentas en Orchestrator. Los usuarios afectados pueden haber visto que las páginas de Orchestrator no se cargan, por ejemplo la página Jobs que devuelve “Ha ocurrido un error”, y operaciones de robots como las transacciones de cola y las sesiones comienzan pueden haber sido programadas intermitentemente. Otros servicios UiPath que dependen de Orchestrator también pueden haber visto respuestas o errores más lentos durante este período. ## Root cause Varias operaciones de Orchestrator usados frecuentemente dependían de un recurso compartido de corta duración dentro de la base de datos, incluyendo el control de estado de rutina que cada robot en funcionamiento realiza. A medida que el volumen de actividad robótica concurrente en esta región creció, las solicitudes comenzaron a colarse para acceder a ese recurso compartido en lugar de completar su trabajo. El efecto fue selectivo en lugar de una desaceleración general: las operaciones que utilizaron este recurso se retrasaron, mientras que otras continuaron funcionando normalmente. Debido a que el procesador, el uso de memoria y almacenamiento de la base de datos permanecían dentro de los rangos normales, el monitoreo de la capacidad rutinaria no indicaba un problema. ## Detection Nuestro monitoreo automatizado detectó la degradación en aproximadamente 35 minutos de inicio del impacto del cliente, y nuestros ingenieros identificaron la contención subyacente durante el evento. Dado que se trataba de un problema de contención en lugar de una escasez de capacidad, y todos los indicadores de capacidad eran normales, no se esperaba que aumentara la capacidad de base de datos para resolverlo, y el equipo investigó alternativas antes de aplicarlo. Esa evaluación retrasó la mitigación. ## Response Nuestro equipo de ingeniería aumentó la capacidad de la base de datos afectada. Los tiempos de respuesta y las tasas de error volvieron a la normalidad inmediatamente, y continuamos monitorizando para confirmar que el servicio estaba estable antes de cerrar el incidente. * 13:00 : Los índices de error y los tiempos de respuesta comienzan a aumentar para los clientes de la región estadounidense. * 13:36 : El monitoreo automatizado detecta la degradación y notifica al equipo de ingeniería en el local. * 13:36 – 17:29 : Los ingenieros investigan. Todos los indicadores estándar de capacidad de base de datos — procesadores, memoria y almacenamiento— permanecen dentro de rangos normales a lo largo de todo, por lo que la causa no es evidente desde el monitoreo rutinario. * 17:29 : Se declara un incidente formal y el equipo de respuesta está comprometido. 17:38 Se publica un aviso público sobre [Estado del Uruguay] (http://status.uipath.com/) \(Investigando\). * 17:31 – 17:43 : Se proporciona capacidad adicional de base de datos para la región afectada. * 18:00 : Tasas de error, tiempos de respuesta y solicitud de latencia volver a los niveles normales. * 18:11 : La página de estado se actualiza para monitorizar " El impacto del cliente termina. * 19:06 : El incidente se cierra después de la vigilancia continua confirma que el servicio es estable. ## Follow up Para evitar que esto suceda de nuevo, somos: * Cambiar las operaciones afectadas para que ya no dependan del recurso compartido. Esto se ha lanzado a todos los sistemas afectados y ha reducido sustancialmente la condición que causó el incidente. * Permitir un monitoreo detallado de bases de datos en estos sistemas, por lo que esta clase de contención es visible mientras está ocurriendo más que después. * Mejorar nuestra alerta para que una verdadera degradación de este tipo sea claramente distinguible de la variación rutinaria, autocorregida, y se escala más rápido.

Traducido automáticamente desde la actualización oficial del incidente.

1. 6 de octubre de 2026 a las 17:50 UTCinvestigating

   Estamos investigando informes de un outage impactante [funcional o síntoma del usuario] para Orchestrator en Europa. Impacto: Los usuarios pueden esperar retrasos para la ingestión de registros de robots y/o búsqueda/display de los registros. No se perderán registros. Siguiente actualización: Nuestros equipos están trabajando para entender la causa y el alcance y compartirán las actualizaciones como están disponibles.

2. 6 de octubre de 2026 a las 18:28 UTCidentified

   Hemos identificado la causa de una ingestión de registros de robots para Orchestrator en Europa. Impacto: Los usuarios pueden esperar retrasos para la ingestión de registros de robots y/o búsqueda/display de los registros. No se perderán registros. Siguiente actualización: Nuestros equipos están trabajando para entender la causa y el alcance y compartirán las actualizaciones como están disponibles.

3. 6 de octubre de 2026 a las 18:43 UTCmonitoring

   Hemos mitigado el problema que impacta la ingestión de registros robot para Orchestrator en Europa. Impacto: Los usuarios pueden esperar retrasos para la ingestión de registros de robots y/o búsqueda/display de los registros. No se perderán registros. Siguiente actualización: Nuestros equipos están trabajando para entender la causa y el alcance y compartirán las actualizaciones como están disponibles.

4. 6 de octubre de 2026 a las 18:44 UTCresolved

   Hemos mitigado el problema que impacta la ingestión de registros robot para Orchestrator en Europa. Impacto: Los usuarios pueden esperar retrasos para la ingestión de registros de robots y/o búsqueda/display de los registros. No se perderán registros. Siguiente actualización: Nuestros equipos están trabajando para entender la causa y el alcance y compartirán las actualizaciones como están disponibles.

5. 7 de octubre de 2026 a las 11:08 UTCpostmortem

   ## Impacto del cliente On , between approximately 15:45 UTC and 18:45 UTC, customers hosted in the Europe, Australia and Japan regions were unable to see recent robot logs in Orchestrator. Los registros escritos durante la ventana de impacto no aparecieron en las vistas de Jobs and Logs o a través de la API de Robot Logs, y los registros mayores de aproximadamente 03:00 UTC ese día estaban disponibles sólo intermitentemente. La ventana de impacto difiere por región: Australia: aproximadamente 15:45 UTC a 18:35 UTC - Europa: aproximadamente 16:35 UTC a 18:00 UTC - Japón: aproximadamente 16:45 UTC a 18:30 UTC La ejecución de trabajo, las colas, los disparadores y todas las demás funcionalidades de Orchestrator no se vieron afectadas. No se perdieron registros de robots. Los registros producidos durante la ventana de impacto continuaron siendo recogidos y se volvieron visibles una vez que se mitigó la cuestión. ## Root cause Estuvimos realizando una actualización programada del servicio Elasticsearch que almacena registros de robots Orchestrator. La actualización utiliza un enfoque azul/verde: se crea un nuevo cluster junto al existente, los datos se restauran en él desde una copia de seguridad, el oleoducto que ingiere nuevos registros se inicia en él, y sólo entonces se cambia el tráfico. En las regiones afectadas, el interruptor de tráfico fue aprobado por el ingeniero que ejecutó la actualización antes de la restauración de datos y la captación de la ingestión había finalizado, lo que es una desviación de nuestro procedimiento de actualización. Esto fue un error humano. Como resultado, Orchestrator estaba leyendo registros de robots de un clúster que aún no contenía datos recientes, mientras que los nuevos registros seguían siendo recogidos pero aún no se indizaron en las solicitudes de cúmulos. El error no fue capturado porque nuestra herramienta de implementación depende del operador para verificar la integridad de los datos y no hace cumplir el orden entre la restauración de datos y el interruptor de tráfico. ## Detection Nuestro monitoreo sintético, que realiza continuamente trabajos de prueba y verifica que sus registros se devuelven, detectan registros perdidos en las regiones afectadas y alertas elevadas. Nuestro equipo de ingeniería correlacionó las alertas con la actualización del proceso, declaró un incidente y publicó una notificación de la página de estado. ## Response Nuestro equipo de ingeniería revertía el tráfico a los grupos anteriores de Elasticsearch en las tres regiones, que inmediatamente restableció el acceso a todos los registros de robots, incluidos los producidos durante la ventana de impacto. Confirmamos la recuperación mediante el monitoreo sintético en cada región afectada y el seguimiento continuo antes de marcar el incidente resuelto a aproximadamente 18:45 UTC. La actualización de los nuevos grupos continúa en el contexto. El tráfico se trasladará a ellos sólo después de que la restauración de datos sea completa y se confirma que la ingestión está actualizada. ## Follow up Para evitar que esto suceda de nuevo, somos: - Cambiar el oleoducto de despliegue para que el interruptor de tráfico no pueda funcionar hasta que se verifique la reiniciación de datos y la ingestión de registros en el nuevo grupo. - Añadiendo un paso automatizado de vuelta a la tubería, por lo que el tráfico puede ser devuelto al grupo anterior en cuestión de minutos si se detecta un problema después de un interruptor.

Traducido automáticamente desde la actualización oficial del incidente.

1. 6 de octubre de 2026 a las 12:38 UTCidentified

   Observamos el rendimiento degradado para servicios en UAE

2. 6 de octubre de 2026 a las 12:43 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

3. 6 de octubre de 2026 a las 14:01 UTCidentified

   Hemos identificado el problema como un problema de enrutamiento de redes con un proveedor de servicios de terceros, afectando la conectividad para nuestros servicios hospedados en el EAU. Estamos trabajando con nuestro proveedor de resolución y actualizaremos el progreso aquí.

4. 6 de octubre de 2026 a las 14:22 UTCidentified

   Seguimos trabajando en una solución para esta cuestión.

5. 6 de octubre de 2026 a las 14:51 UTCmonitoring

   Estamos monitoreando la conectividad y actualizaremos esta página una vez que se confirme la estabilidad.

6. 6 de octubre de 2026 a las 15:09 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

7. 6 de octubre de 2026 a las 17:09 UTCresolved

   El incidente se ha resuelto.

8. 21 de octubre de 2026 a las 5:36 UTCpostmortem

   ## Impacto del cliente Entre las 12:38 PM UTC y las 2:51 PM UTC, un subconjunto de clientes en la región de los Emiratos Árabes Unidos experimentó fallos al acceder a servicios en la nube de UiPath. El incidente duró aproximadamente 2 horas y 13 minutos. Los servicios afectados incluían el acceso a **cloud.uipath.com**, **account.uipath.com** Servicios hospedados en UAE. Los clientes pueden haber encontrado timeouts, autenticación fallida, conexiones de reset, o errores del servidor. ## Root cause La causa raíz fue una falla de enrutamiento de redes regionales en un proveedor de infraestructura de terceros. Un subconjunto de rutas de red desde la región de UAN a redes externas específicas, incluyendo la red de distribución de contenidos que sirve **cloud.uipath.com** y **account.uipath.com**, dejaron de entregar el tráfico. Los nuevos intentos de conexión saliente de los servicios afectados no recibieron respuestas, lo que hizo que las solicitudes llegaran a tiempo. Nuestro equipo de ingeniería descarta la configuración del servicio UiPath, la política de nivel de aplicación y la capacidad de conexión externa como causas. El proveedor de infraestructura reconoció un problema conocido que afectaba a múltiples clientes en la misma vía de red. ## Detection La cuestión se detectó mediante un control automatizado. Aproximadamente a las 12:40 pm UTC — aproximadamente dos minutos después del inicio del fracaso— la investigación confirmó que fallaban las nuevas conexiones de los servicios de la región UAN afectados a los puntos finales clave de UiPath. ## Response Para 1:20 pm UTC, nuestro equipo de ingeniería confirmó que el fracaso estaba limitado a rutas de red externas específicas, mientras que otros destinos seguían siendo accesibles. La validación descarta los cambios de enrutamiento del lado UiPath, los cambios de configuración de la entrega de contenidos, la política de nivel de aplicación y los problemas de capacidad de conexión. Se abrió un caso de apoyo de alta perseverancia con el proveedor de infraestructura de terceros. A las 1:50 pm UTC, el proveedor reconoció un problema conocido que afectaba a múltiples clientes. Nuestro equipo siguió monitoreando la recuperación de las rutas de red afectadas y verificando la salud de los servicios cuando el tráfico regresó. A las 2:51 pm UTC, los cheques de recuperación confirmaron que el tráfico UiPath a través de las rutas de entrega de contenidos afectadas había retornado a niveles normales. Controles de salud automatizados y métricas de servicio confirmados de recuperación, y Servicios en UAN estaban operativos. ## Follow up 1. Estamos persiguiendo la acción correctiva confirmada por el proveedor de infraestructura y el análisis de causa raíz para el fracaso regional de enrutamiento. 2. Estamos examinando las dependencias de servicios externas en la región afectada para fortalecer la resiliencia contra perturbaciones similares de la red de terceros.

Traducido automáticamente desde la actualización oficial del incidente.

1. 2 de octubre de 2026 a las 16:23 UTCinvestigating

   Desde alrededor de 15:05 UTC, algunos clientes en la región de Estados Unidos pueden ver trabajos que funcionan en Cloud Robots tardan más de lo habitual en empezar, o permanecer en el estado de Pending. Los trabajos en sus propios robots no están afectados, y tampoco son otras regiones. Hemos encontrado la causa probable y estamos trabajando para restaurar el procesamiento normal del trabajo. Los empleos que ya están demandados no se pierden y serán procesados una vez resuelto el problema. Publicaremos otra actualización dentro de 60 minutos.

2. 2 de octubre de 2026 a las 16:34 UTCmonitoring

   Hemos aplicado una solución para el problema que retrasa los empleos en Cloud Robots en la región de Estados Unidos, y los empleos comienzan normalmente de nuevo. Los trabajos que se retrasaron están siendo procesados. Estamos monitoreando para asegurarnos de que el servicio permanezca estable y publicaremos otra actualización dentro de 60 minutos.

3. 2 de octubre de 2026 a las 16:51 UTCmonitoring

   Después de trabajar más sobre el tema, los empleos en Cloud Robots en la región de Estados Unidos están empezando normalmente. Se están tramitando trabajos que se retrasaron antes. Continuamos monitoreando el servicio y publicaremos otra actualización una vez resuelto el problema.

4. 2 de octubre de 2026 a las 17:03 UTCresolved

   Esta cuestión se ha resuelto. Entre 15:05 y 16:39 UTC, los trabajos en Cloud Robots en la región de Estados Unidos fueron lentos para empezar o permanecer en el estado de Pending. Los empleos han comenzado normalmente desde 16:39 UTC, y los trabajos que se retrasaron durante este tiempo han sido procesados. Nos disculpamos por la interrupción.

5. 14 de octubre de 2026 a las 14:20 UTCpostmortem

   ## Impacto del cliente De 15:00 a 16:38 UTC el 2026-10-02, los trabajos de Cloud Robots en la región de Estados Unidos tardaron más de lo habitual en comenzar, hasta 22 minutos en el pico alrededor de 16:20 UTC. Orchestrator permaneció disponible, no se perdió trabajo, ninguna otra región fue afectada. Un pequeño número de clientes recibieron un error de límite temporal en nuevas presentaciones mientras sus trabajos anteriores estaban esperando. ## Detection Alertas automatizadas disparadas a las 15:07 UTC, siete minutos después del inicio del impacto. Los cheques en la región de Estados Unidos fallaron de alrededor de 15:32 UTC y la respuesta del incidente comenzó. ## Root cause A las 14:55 UTC el flujo de trabajo de un cliente comenzó a enviar trabajos a unas 20 veces su tasa normal. El servicio que admite trabajos mantiene un recuento de concurrencia por cliente en la base de datos y lo actualiza bajo un bloqueo de bases de datos en cada inicio y final de trabajo. A ese ritmo, la cola de bloqueo para el registro del cliente creció hasta que las actualizaciones se agotaron. Las actualizaciones de espera ocuparon la piscina compartida de trabajadores que inician trabajos para todos los clientes de la región, así que los trabajos de cada cliente esperaban detrás de ellos. El mecanismo significaba aislar la carga de un cliente se convirtió en el cuello de botella. ## Response El equipo identificó la vía de admisión sobrecargada y el volumen de trabajo detrás de ella. Un primer cambio de configuración a las 15:46 UTC apuntaba al registro equivocado y no tenía ningún efecto. El cambio correcto a las 16:10 UTC eximió el tipo de trabajo del cliente del bloqueo de la base de datos y entró en vigor alrededor de 16:20 UTC. Los tiempos de inicio disminuyeron de aproximadamente 13 segundos a menos de un segundo y el atraso de unos 5200 trabajos se agotó en 18 minutos. El trabajo comienza normal a las 16:38 UTC. El gatillo del cliente fue apagado con el cliente a unas 16:40 UTC. ## Follow up La limitación de la tasa bloqueada de la base de datos es reemplazada por un mecanismo de limitación de alta tasa de rendimiento en memoria, por lo que la carga de un cliente no puede bloquear el trabajo comienza por otros. El cambio es completo, probado en preproducción a la misma carga, y siendo lanzado.

Traducido automáticamente desde la actualización oficial del incidente.

1. 2 de octubre de 2026 a las 0:13 UTCinvestigating

   Actualmente estamos investigando un outage que afecta al portal Insights en la región de los EAU. Los usuarios de esta región pueden ser incapaces de acceder al portal o pueden experimentar cargas de página fallidas. Nuestro equipo está trabajando activamente para identificar la causa y restaurar el servicio. Proporcionaremos otra actualización tan pronto como tengamos más información.

2. 2 de octubre de 2026 a las 0:36 UTCidentified

   Hemos identificado un camino de mitigación y estamos empezando un retroceso en la región de los Emiratos Árabes Unidos. Los usuarios pueden seguir experimentando problemas de acceso intermitente con el portal Insights mientras este trabajo está en marcha. Proporcionaremos otra actualización una vez que la devolución esté completa.

3. 2 de octubre de 2026 a las 0:41 UTCmonitoring

   El portal Insights en la región de los Emiratos Árabes Unidos se está cargando con éxito tras nuestro retroceso. Seguimos monitoreando el servicio para confirmar la estabilidad y proporcionaremos una actualización final una vez que confiamos en que la cuestión está totalmente resuelta.

4. 2 de octubre de 2026 a las 0:51 UTCresolved

   El portal Insights en la región de los Emiratos Árabes Unidos está operando normalmente después de la devolución. Hemos validado la funcionalidad del portal clave y confirmado que el servicio sigue siendo saludable. Este incidente ya está resuelto.

5. 5 de octubre de 2026 a las 22:58 UTCpostmortem

   ## Impacto del cliente El 1 de octubre de 2026**, el servicio UiPath ** Insights** en la región **EAU** no estaba disponible. Desde aproximadamente **23:40 UTC el 1 de octubre a 00:39 UTC el 2 de octubre**, los usuarios no pudieron cargar los paneles de Insights: las solicitudes fallaron con un error después de unos 10 segundos. Tampoco se recibieron solicitudes de información sobre nuevos inquilinos en la región. La interrupción duró aproximadamente **59 minutos**. Other UiPath services in the UAE region, and Insights in all other regions, were not affected. No se perdieron datos de clientes. ## Root Cause El outage fue causado por un ** cambio de configuración** que se envió en un lanzamiento de Insights programado. El cambio aumentó la versión **minimum TLS \(Transport Layer Security\)** en los puntos finales de aplicación Insights en la región de los Emiratos Árabes Unidos de TLS 1.2 a **TLS 1.3**, como parte de un esfuerzo de endurecimiento de la seguridad. El portal UiPath que recorre el tráfico de clientes a Insights se conecta a estos puntos finales sobre TLS 1.2. Una vez que los puntos finales dejaron de aceptar TLS 1.2, la puerta de entrada ya no podía abrir una conexión segura con ellos. Las solicitudes de clientes se agotaron y devolvieron errores, aunque la aplicación Insights se mantuvo sana. El cambio se aplica únicamente a la región de los Emiratos Árabes Unidos, razón por la cual ninguna otra región se vio afectada. ## Detection El problema fue detectado por **El monitoreo sintético automatizado de UiPath**, que prueba continuamente la disponibilidad de Insights desde múltiples ubicaciones. El primer cheque de salud fallido fue registrado a las 23:40 UTC. Alertas automatizadas disparadas en cuestión de minutos, y el equipo de ingeniería de guardia comenzó a investigar. ## Response El equipo de ingeniería confirmó que el outage afectaba solamente a Insights en la región de los Emiratos Árabes Unidos. La aplicación se estaba ejecutando normalmente, pero ningún tráfico de clientes lo estaba alcanzando. El equipo rastreó el fracaso del paso de conexión segura entre la puerta de entrada y los Insights, y lo vinculó al ajuste TLS aplicado por la liberación. Aproximadamente **00:38 UTC**, el equipo restauró la versión mínima anterior de TLS \(TLS 1.2\) en los puntos finales afectados. Los cheques de salud sintéticos comenzaron a pasar inmediatamente, y por **00:41 UTC** todos los cheques de Insights en la región de los EAU eran saludables. El equipo siguió monitoreando para confirmar la plena estabilidad. ## Follow-Up Para evitar incidentes similares en el futuro, estamos tomando las siguientes medidas: * **Remove the TLS change from the release** so that future deployments do not re-apply it, until the gateway supports TLS 1.3 end to end. * **Cambios de conexión-seguridad de valor contra la puerta** en un entorno preproducción antes de que se apliquen a la producción.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de octubre de 2026 a las 18:57 UTCinvestigating

   A partir del 1 de octubre a aproximadamente 1:30 PM UTC, algunos Agentes, incluyendo agentes de código bajo y codificados, comenzaron a experimentar fallos en todas las regiones al utilizar gemini-3.1-pro-preview y gpt-4o-2024-05-13. Estos modelos también pueden estar disponibles para la selección durante el diseño del agente. Estamos investigando y trabajando activamente en una solución.

2. 1 de octubre de 2026 a las 19:05 UTCidentified

   Hemos identificado el problema y estamos implementando una solución. Los agentes que utilizan los modelos afectados pueden seguir experimentando fallos, y los modelos pueden permanecer indisponibles para la selección durante el diseño del agente, mientras que el despliegue se completa.

3. 1 de octubre de 2026 a las 19:46 UTCresolved

   Hemos revertido el cambio que causó este problema y confirmado que los modelos afectados están disponibles de nuevo. Algunos agentes pueden seguir experimentando fallos intermitentes mientras que los casos se refrescan. Seguimos monitoreando el diseño y ejecución de agentes para gemini-3.1-pro-preview y gpt-4o-2024-05-13.

4. 7 de octubre de 2026 a las 10:15 UTCpostmortem

   ## Impacto del cliente El 1 de octubre de 2026, de 14:31 a 19:40 UTC, agentes configurados con algunos modelos de lenguaje grandes, incluyendo Gemini 3.1 Pro Preview y GPT-4o (2024-05-13), no comenzaron en todas las regiones, con un error diciendo que el modelo no está disponible. Los mismos modelos faltaban de la lista de modelos mientras diseñaban agentes. Los agentes que utilizan otros modelos no se vieron afectados. ## Root cause Una bandera de características fue volteada, haciendo que el servicio de Agentes comience a enviar un código de operación para modelar solicitudes de descubrimiento. Esto causó la lista de modelos servidos para ser esa operación específica en lugar de la lista de modelos de agentes base. La lista de modelos de operación se fijó inicialmente de la configuración de Bring Your Own Model (BYOM) de modelos sobreridables, que crucialmente para los agentes no tenían paridad con la lista completa de modelos soportados en el servicio de Agentes. La auditoría interna mostró que esto era un error y no una brecha intencional. Con el tiempo esta brecha nunca fue abordada y después del cambio de bandera, los agentes ya configurados con cualquiera de los modelos afectados fallarían debido a su ausencia de la lista devuelta. ## Detection Un cliente reportó el problema, y fue escalada a nuestros ingenieros a las 16:44 UTC. Nuestro monitoreo no alertó, porque este error generalmente apunta a cuestiones de configuración de nivel de organización o agente. ## Response Los ingenieros rastrearon los fallos del cambio de configuración y lo revertieron a las 19:01 UTC. El revertido tuvo efecto en los siguientes minutos, y el último fallo ocurrió a las 19:40 UTC. ## Follow up 1. Las listas modelo se alinearán antes de que este cambio se haga de nuevo. 2. Estamos cambiando cómo se clasifica este error para que un pico de toda la plataforma alerte a nuestros ingenieros.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de octubre de 2026 a las 18:17 UTCinvestigating

   A partir del 1 de octubre aproximadamente a las 12:00 PM UTC, los usuarios comunitarios de Europa pueden experimentar fallos en LowCode Agents que utilizan aplicaciones de acción local de solución. Hemos confirmado que el impacto se limita a los usuarios comunitarios en Europa. Estamos investigando activamente la cuestión, determinando el alcance de los fracasos y trabajando en una solución.

2. 1 de octubre de 2026 a las 18:25 UTCidentified

   Hemos identificado el problema causando fracasos en agentes de código bajo que utilizan aplicaciones de acción local de solución para usuarios comunitarios en Europa. Estamos retrocediendo los cambios anteriores y continuamos monitoreando la recuperación. Proporcionaremos otra actualización una vez que la devolución sea completa o si tenemos información adicional para compartir.

3. 1 de octubre de 2026 a las 20:08 UTCresolved

   Hemos confirmado que la devolución se ha completado y se ha resuelto el problema que afecta a los agentes de código bajo que utilizan aplicaciones de acción local de soluciones para usuarios comunitarios en Europa. Los servicios se han recuperado, y estamos cerrando este incidente.

4. 7 de octubre de 2026 a las 14:28 UTCpostmortem

   ## Impacto del cliente El 1 de octubre de 2026, de 10:50 a 19:50 UTC, algunos usuarios de Studio Web en Europa no pudieron depurar agentes que llaman procesos Orchestrator (RPA, agentes, etc.) o aplicaciones de acción de la misma solución. La llamada falló con un error "no encontrado". Los agentes publicados y los trabajos de producción no se vieron afectados. ## Root cause Una actualización de Studio Web cambió cómo se ubican los recursos de solución durante la depuración. Se perdió un entorno que mantiene el comportamiento anterior, así que debug corre buscando los recursos de la solución en el espacio de trabajo personal del usuario en lugar de la carpeta de depuración. ## Detection Pruebas automáticas de extremo a extremo alertaron a nuestros ingenieros a las 16:43 UTC. La suite de pruebas de extremo a extremo funciona una vez cada 2 horas y la alerta sólo sucede después de 3 fallos de prueba consecutivos. El problema también se reportó desde un entorno de clientes. ## Response Después de identificar la causa raíz, se inició un retroceso a las 18:00 UTC y estaba totalmente en vigor a las 19:50 UTC. Esta duración incluyó una falla de despliegue que tuvo que ser retratada, que tomó 50 minutos. Una versión corregida que incluye el ajuste fue desplegada el 2 de octubre a las 13:00 UTC. ## Follow up 1. El ajuste es ahora parte de la línea de código principal, por lo que las versiones futuras lo incluyen. 2. Estamos mejorando las alertas y la suite de pruebas de extremo a extremo para capturar regresiones antes.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de octubre de 2026 a las 16:32 UTCresolved

   Entre 14:23 y 16:04 UTC el 1 de octubre de 2026, algunas solicitudes para eliminar artículos en los servicios UiPath Automation Cloud en la región de Australia fallaron con errores "404 No se encontró". Los servicios afectados incluyeron Orchestrator, Document Understanding, AI Center y Data Service. Otras operaciones, como ver, crear y actualizar artículos, funcionaban normalmente. La causa fue un cambio de configuración a nuestra solicitud de enrutamiento. La volamos y el servicio está completamente restaurado.

2. 7 de octubre de 2026 a las 10:15 UTCpostmortem

   ## Impacto del cliente Entre el 1 de octubre de 2026 a las 14:23 pm UTC y 4:04 pm UTC, un subconjunto de clientes experimentado **404 No encontrado** errores para algunas solicitudes UiPath Automation Cloud en la región de Australia. El incidente duró 1 hora y 41 minutos. Las solicitudes afectadas incluyeron operaciones de eliminación y algunos controles de conexión Robot. Los servicios afectados incluyeron Orchestrator, Document Understanding, AI Center y Data Service. Los empleos de robot que llamaron Orchestrator pueden haber fracasado, y los clientes pueden necesitar rehacer cualquier trabajo de Robot que falló durante esta ventana. Todas las demás operaciones no se vieron afectadas. ## Root cause Se aplicó un cambio de configuración de enrutamiento a la región de Australia con un conjunto incompleto de operaciones soportadas debido a un tiempo en el oleoducto de liberación. Eliminar las operaciones faltaban de la configuración, por lo que esas solicitudes fueron rechazadas en la capa de enrutamiento con **404 No encontrado** antes de llegar a los servicios subyacentes. ## Detection El monitoreo automatizado de extremo a extremo detectó el problema al alertar sobre fallos en los controles de servicio de Entendimiento de Documentos. Nuestro equipo de ingeniería utilizó datos de monitoreo interno para confirmar el patrón más amplio de fallas en los servicios afectados. ## Response During investigation, monitoring data showed that requests routed through the Australia region were returning **404 Not Found** errors, while requests routed through other regions were un affected. El análisis identificó que el tiempo de inicio de **404 No se encontró** aumento de la respuesta estaba correlacionado con el momento en que la configuración de enrutamiento entró en vigor. El equipo revertía la configuración de enrutamiento a la versión de trabajo anterior. Después de la reversión, el monitoreo mostró que los recuentos de errores caen en aproximadamente tres minutos, y el servicio fue restaurado completamente para el 1 de octubre de 2026 a las 4:04 pm UTC. ## Follow up 1. Mejorar las alertas de la capa de enrutamiento sobre los cambios de base de 4xx 2. Detectar configuraciones de enrutamiento parcialmente aplicadas antes de que surtan efecto

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de octubre de 2026 a las 13:21 UTCinvestigating

   Nuestro equipo está trabajando activamente en una solución para el rendimiento degradado que afecta a Orchestrator en la región de Estados Unidos. Compartiremos actualizaciones a medida que se avance.

2. 1 de octubre de 2026 a las 14:06 UTCidentified

   Actualmente se está implementando una solución para el rendimiento degradado que afecta a Orchestrator y Action Center en la región de Estados Unidos. Seguirán nuevas actualizaciones.

3. 1 de octubre de 2026 a las 14:24 UTCmonitoring

   Se ha implementado una solución para el rendimiento degradado que afecta a Orchestrator y Action Center en la región de Estados Unidos. Nuestro equipo está monitoreando activamente los resultados para confirmar que la cuestión está totalmente resuelta.

4. 1 de octubre de 2026 a las 17:58 UTCmonitoring

   Se ha implementado una solución para el rendimiento degradado que afecta a Orchestrator y Action Center en la región de Estados Unidos. Seguimos monitoreando el desempeño y la estabilidad del sistema para confirmar que la cuestión está plenamente resuelta. Se proporcionarán más actualizaciones a medida que se disponga de más información.

5. 1 de octubre de 2026 a las 19:03 UTCresolved

   Se ha resuelto el rendimiento degradado que afecta a Orchestrator y Action Center en la región de Estados Unidos. El desempeño de los sistemas ha permanecido estable tras la solución aplicada, y continuaremos la vigilancia estándar.

6. 5 de octubre de 2026 a las 6:40 UTCpostmortem

   ## Impacto del cliente Entre las 11:00 UTC y las 13:40 UTC el 1 de octubre de 2026, los clientes de la región de EE.UU. observaron tiempos de respuesta más lentos de Orchestrator y tiempo intermitente. Los robots tardaron más en iniciar trabajos, procesar artículos de cola y leer activos, y algunas de estas solicitudes fracasaron. Otros servicios UiPath que dependen de Orchestrator también fueron afectados mientras Orchestrator fue degradado, y puede haber visto respuestas más lentas o errores. ## Root cause Un despliegue de fijación de Orchestrator incluyó un cambio en cómo la capacidad de cálculo está reservada y escalada para nuestros servicios. El cambio estaba destinado a utilizar nuestra infraestructura de manera más eficiente, pero redujo la capacidad de procesamiento disponible para Orchestrator. Durante períodos ocupados nuestro escalado automático no añadió la capacidad como se esperaba, por lo que el servicio no podía mantenerse al día con la demanda. ## Detection Nuestro monitoreo interno detectó la desaceleración después de la actualización. Nuestro primer plan fue lanzar una actualización corregida a través de nuestro proceso de liberación estándar, que lleva varias horas. Cuando los informes del cliente comenzaron a entrar, abrimos un incidente y nos mudamos a una solución más rápida. ## Response Nuestro equipo de ingeniería aplicó los ajustes de capacidad anteriores directamente a los servicios afectados, sin esperar la actualización corregida. Los tiempos de respuesta volvieron a la normalidad aproximadamente a las 13:40 UTC, y continuamos monitoreando para confirmar que el servicio era estable. ## Follow up Para evitar que esto suceda de nuevo, somos: - Restaurar permanentemente los ajustes de capacidad anteriores y revisar cualquier cambio de capacidad futuro contra la carga a nivel de producción antes de la puesta en marcha. - Mejorar la forma de evaluar el impacto del cliente durante las degradaciones, por lo que se intensifican hasta un incidente anterior. - Hacer que sea más rápido para revertir cambios de capacidad y configuración cuando afectan a los clientes.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de octubre de 2026 a las 4:12 UTCinvestigating

   Estamos investigando el rendimiento degradado que impacta el servicio UiPath desde LLM Gateway en varias regiones. Nuestros equipos están trabajando para identificar la causa y compartiremos más detalles a medida que avanza la investigación.

2. 1 de octubre de 2026 a las 5:42 UTCmonitoring

   Se ha aplicado una solución, y nuestro equipo está monitoreando activamente los resultados para confirmar la cuestión está plenamente resuelto.

3. 1 de octubre de 2026 a las 6:28 UTCmonitoring

   Seguimos vigilando los resultados de la solución aplicada para asegurar que la cuestión se resuelva plenamente.

4. 1 de octubre de 2026 a las 7:48 UTCresolved

   La cuestión se ha resuelto y los servicios funcionan normalmente. Nos disculpamos por cualquier inconveniente que esto pueda haber causado.

5. 6 de octubre de 2026 a las 14:35 UTCpostmortem

   ## Impacto del cliente Entre el 1 de octubre de 2026 a las 03:00 UTC y el 1 de octubre de 2026 a las 04:10 UTC, un subconjunto de clientes experimentó fallos intermitentes al utilizar funciones impulsadas por AI, incluyendo Context Grounding, Agent Builder y Agents, Autopilot para desarrolladores, actividades generativas de IA y Minería de Comunicaciones. Impacto de las solicitudes atendidas por nuestra infraestructura de servicios de IA Europa o en ruta. Entre las regiones afectadas figuran los Emiratos Árabes Unidos, Corea, Suiza, Reino Unido, India, Singapur, Australia y Europa. Los clientes vieron solicitudes fallidas, incluyendo errores no disponibles en el servicio. Las fallas se concentraron durante dos períodos 03:00 UTC a 03:45 UTC y 04:00 UTC a 04:08 UTC para una ventana total de incidentes de aproximadamente 1 hora y 10 minutos. ## Root cause Una sola carga de trabajo de procesamiento de imágenes envió una gran cantidad de solicitudes con cargas de imagen muy grandes a nuestra infraestructura de servicios de Europa AI. Esos órganos de solicitud de gran tamaño provocaron que las instancias de servicio agoten la memoria disponible, se tornaron inresponsables y se reiniciaron. A medida que bajaba la capacidad saludable, nuestros sistemas devolvieron errores no disponibles para el tráfico de clientes. Cuando el tráfico fue redirigido automáticamente a un segundo lugar de Europa, el mismo patrón de fracaso ocurrió porque ambos lugares recibieron el mismo volumen de trabajo sobredimensionado. ## Detection Nuestros sistemas de monitoreo generaron múltiples alertas simultáneas poco después de que los fallos comenzaron aproximadamente a las 03:00 UTC. Durante la investigación inicial, nuestro equipo de ingeniería confirmó que las fallas de servicio de Europe AI causaban errores en múltiples productos y regiones. ## Response Durante la investigación, nuestro equipo de ingeniería identificó el volumen de trabajo fuente y definió las opciones de mitigación: detener la carga de trabajo en su fuente, o bloquear su tráfico antes de que llegara a los servicios afectados. Como medida de estabilización a corto plazo, se aumentaron los límites de memoria de los servicios. Telemetry confirmó dos períodos de fracaso 03:00 UTC a 03:45 UTC y 04:00 UTC a 04:08 UTC. Para 04:10 UTC, los errores no disponibles en el servicio habían bajado a cerca de cero y no se observaron reiniciamientos de servicio adicionales. A continuación se aplicó un bloque de tráfico para evitar que el volumen de trabajo de la fuente llegara a los servicios afectados. Se confirmó que el volumen de trabajo de la fuente se había detenido aproximadamente a las 04:46 UTC, y no se observó más tráfico después. ## Follow up 1. Estamos añadiendo cumplimiento a nivel de servicio para rechazar o manejar de forma segura las cargas de pago de imagen sobredimensionadas antes de que puedan agotar la memoria del servicio. 2. Estamos añadiendo un límite de concurrencia por organización para el procesamiento de imágenes de Context Grounding para evitar que una sola carga de trabajo afecte la disponibilidad de servicios para otros clientes.

Traducido automáticamente desde la actualización oficial del incidente.

1. 26 de septiembre de 2026 a las 16:46 UTCinvestigating

   Estamos investigando problemas con los caminos de ejecución del Maestro en la región del Reino Unido. Algunos clientes pueden observar el rastro de ejecución perdido. No hay impacto en las ejecuciones de instancia.

2. 26 de septiembre de 2026 a las 17:15 UTCidentified

   Hemos identificado la causa del problema que afecta a los caminos de ejecución del Maestro en la región del Reino Unido y estamos trabajando en una solución.

3. 26 de septiembre de 2026 a las 17:46 UTCmonitoring

   Se ha aplicado una solución para la cuestión que afecta a los caminos de ejecución del Maestro en la región del Reino Unido, y se registran normalmente nuevas rutas de ejecución. Estamos restaurando los caminos de ejecución desaparecidos para las ejecuciones afectadas y estamos monitoreando los resultados. Las ejecuciones de emergencia no se vieron afectadas.

4. 26 de septiembre de 2026 a las 18:58 UTCmonitoring

   La solución para los senderos de ejecución del Maestro en la región del Reino Unido se mantiene, y se siguen registrando nuevos senderos normalmente. Todavía estamos trabajando en la restauración de los caminos perdidos para las ejecuciones afectadas y proporcionaremos otra actualización cuando eso esté completo.

5. 26 de septiembre de 2026 a las 20:22 UTCmonitoring

   Continuamos restaurando los caminos de ejecución Maestro desaparecidos en la región del Reino Unido. Los nuevos senderos de ejecución no son afectados y siguen siendo registrados normalmente. Compartiremos otra actualización a medida que se avance.

6. 26 de septiembre de 2026 a las 21:39 UTCmonitoring

   La restauración de los caminos de ejecución Maestro desaparecidos en la región del Reino Unido está progresando, y una parte de los senderos afectados se han recuperado. Se está trabajando para restaurar el resto.

7. 26 de septiembre de 2026 a las 22:55 UTCmonitoring

   La restauración de los caminos de ejecución Maestro desaparecidos en la región del Reino Unido está casi completa. Estamos terminando el trabajo restante y esperamos resolver este incidente en breve.

8. 27 de septiembre de 2026 a las 0:07 UTCmonitoring

   Estamos en la etapa final de restaurar los caminos de ejecución Maestro desaparecidos en la región del Reino Unido, con sólo un pequeño número de senderos restantes. Esperamos que la restauración se complete pronto y publicaremos una actualización final una vez resuelto este incidente.

9. 27 de septiembre de 2026 a las 0:36 UTCresolved

   Este incidente ha sido resuelto. Todos los caminos de ejecución del Maestro desaparecidos en la región del Reino Unido han sido restaurados, y se están registrando nuevas rutas de ejecución normalmente. Las ejecuciones de urgencia no fueron impactadas en ningún momento. Nos disculpamos por la molestia que esto pudo haber causado.

Traducido automáticamente desde la actualización oficial del incidente.