Historial de interrupciones de Uipath

1. September 3, 2026 at 3:34 PM UTCinvestigating

   Actualmente estamos investigando el tema

2. September 3, 2026 at 3:39 PM UTCidentified

   Se determinó la cuestión y se aplicaron las medidas de mitigación apropiadas para abordarla.

3. September 3, 2026 at 3:47 PM UTCmonitoring

   La cuestión se ha resuelto con éxito y el servicio ha sido totalmente restaurado. El servicio funciona normalmente en este momento.

4. September 3, 2026 at 4:17 PM UTCresolved

   La cuestión se ha resuelto con éxito y el servicio ha sido totalmente restaurado. El servicio funciona normalmente en este momento.

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

1. September 4, 2026 at 5:48 PM UTCresolved

   El panel Insights en Looker experimentó un problema que impidió que las últimas carreras del Maestro aparecieran en el panel Regiones afectadas : US, SEA, IND, CA, AUE,JP ,UK Plazo de incidentes Inicio: 2 de septiembre de 2026 a las 20:00:00 UTC Resuelto: 4 de septiembre de 2026 a las 16:30:00 UTC El problema se ha resuelto actualmente, y el panel Insights muestra los últimos datos de ejecución del Maestro.

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

1. September 1, 2026 at 1:49 PM UTCinvestigating

   Estamos investigando informes sobre la digitalización y extracción de resultados degradados para la comprensión de documentos y IXP en Estados Unidos. Impacto: Los usuarios pueden experimentar lentitud y falló Document Understanding runtime operations. Nuestros equipos están trabajando para identificar la causa y compartirán más detalles a medida que avanza la investigación.

2. September 1, 2026 at 2:07 PM UTCmonitoring

   Hemos identificado la cuestión y aplicado una mitigación. Los servicios son devueltos a estado saludable y estamos monitoreando los servicios.

3. September 1, 2026 at 3:06 PM UTCresolved

   Esta cuestión se ha resuelto plenamente y los servicios son estables ahora. Publicaremos más detalles del incidente a la página de estado pronto.

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

1. August 31, 2026 at 4:55 PM UTCinvestigating

   Actualmente estamos investigando el tema.

2. August 31, 2026 at 5:07 PM UTCidentified

   Hemos identificado la cuestión y aplicado la solución necesaria

3. August 31, 2026 at 6:24 PM UTCmonitoring

   La cuestión se ha mitigado y el servicio está en funcionamiento. Seguiremos vigilando de cerca la salud de los servicios y tomaremos nuevas medidas si es necesario.

4. August 31, 2026 at 7:39 PM UTCresolved

   La cuestión se ha mitigado y el servicio está en funcionamiento. Seguiremos vigilando de cerca la salud de los servicios y tomaremos nuevas medidas si es necesario.

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

1. August 28, 2026 at 3:41 PM UTCidentified

   Se ha identificado la cuestión y el equipo está trabajando activamente en el despliegue de una solución. Esperamos que el despliegue comience en las próximas horas.

2. August 28, 2026 at 5:27 PM UTCmonitoring

   Hemos identificado la causa raíz del rendimiento degradado y estamos en el proceso de implementar una solución en las próximas horas. Afecta las consultas vinculadas donde el usuario no tiene acceso a la carpeta original. La superficie de API no está afectada. La exportación mediante CSV se puede utilizar como solución de trabajo. Se proporcionarán actualizaciones adicionales mientras avanzamos hacia la resolución.

3. August 28, 2026 at 5:39 PM UTCidentified

   Hemos identificado la causa raíz del rendimiento degradado y estamos en el proceso de implementar una solución en las próximas horas. Afecta las consultas vinculadas donde el usuario no tiene acceso a la carpeta original. La superficie de API no está afectada. La exportación mediante CSV se puede utilizar como solución de trabajo. Se proporcionarán actualizaciones adicionales mientras avanzamos hacia la resolución.

4. August 28, 2026 at 8:00 PM UTCidentified

   La solución se está aplicando actualmente. Presentaremos otra actualización poco después de que el despliegue se haya completado en todas las regiones afectadas.

5. August 28, 2026 at 10:57 PM UTCresolved

   La solución ha sido implementada con éxito en todas las regiones, y hemos validado que la cuestión se resuelve. El servicio funciona como se espera.

6. September 3, 2026 at 8:49 AM UTCpostmortem

   ## Impacto del cliente Entre el 28 de agosto de 2026 a las 3:23 pm UTC y el 28 de agosto de 2026 a las 10:57 pm UTC, un subconjunto de clientes experimentó errores al abrir los paneles de detalles del artículo de la cola en Orchestrator. El camino afectado devolvió una página 404 para las colas LINKED cuando el usuario NO tenía acceso a la carpeta original en la que se crearon los elementos. El impacto afectó sólo las interacciones de Orchestrator UI y se extendió a todas las regiones que ejecutan la versión de software afectada. El acceso a la interfaz de programación de aplicaciones de Orchestrator no fue afectado, y los datos de cola exportadora a CSV estaban disponibles como solución de trabajo. La duración total fue de aproximadamente 7 horas. ## Root cause El incidente fue causado por una regresión en la interfaz de usuario de Orchestrator para colas vinculadas accedidas desde otras carpetas. La regresión no se ocupó correctamente del flujo de detalles enlazados cuando el usuario solicitante carecía de acceso a la carpeta original, lo que causó que el panel de detalles del artículo de la cola llegara a una página 404 en lugar de mostrar la información esperada. ## Detection El problema fue detectado a través de una alerta de incidentes automatizada para el extremo frontal de Orchestrator el 28 de agosto de 2026 a las 3:23 pm UTC. ## Response A las 3:31 pm UTC el 28 de agosto de 2026, nuestro equipo de ingeniería describió el problema ya que los clientes no podían acceder a los paneles de detalles de artículos de cola debido a una regresión. A las 3:41 pm UTC, una actualización del estado público confirmó que se había identificado la causa raíz, que se estaba implementando una solución, y que el acceso a la interfaz de programación de aplicaciones no era afectado. A las 5:27 pm UTC, el alcance se redujo a colas vinculadas donde el usuario no tenía acceso a la carpeta original. A las 5:29 pm UTC, el equipo determinó que la solución inicial no abordaba completamente el escenario afectado, y se desarrolló una solución corregida. A las 5:30 pm UTC, el escenario afectado fue reproducido y la solución corregida fue validada localmente. A las 5:39 pm UTC, una actualización de la página de estado documentó exportación CSV como una solución de trabajo. El despliegue de la solución corregida continuó en todas las regiones afectadas. A las 10:50 pm UTC, la solución fue confirmada desplegada en todas partes. A las 10:57 pm UTC, el incidente fue marcado resuelto y la página de estado fue actualizada para confirmar que el servicio estaba operando como se esperaba. ## Follow up Las medidas de seguimiento formal se están realizando mediante el proceso de examen posterior al incidente iniciado en la resolución. ## Action items - Ampliar nuestros casos de prueba automatizados para incluir este escenario, y otros escenarios similares relacionados con objetos vinculados o escenarios cruzados. - Asegurarnos de que podamos apagar con seguridad cualquier cambio a través de una bandera durante un tiempo de respuesta más rápido.

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

1. August 27, 2026 at 5:16 PM UTCinvestigating

   Estamos investigando informes de registros de robots desaparecidos en la región de Estados Unidos. Nuestros equipos están trabajando para identificar la causa y compartirán más detalles a medida que avanza la investigación.

2. August 27, 2026 at 6:53 PM UTCidentified

   Identificamos que la ingestión de registros robot se retrasaba. Los registros de robot están llegando a los datos vivos y estamos monitoreando la recuperación.

3. August 27, 2026 at 8:31 PM UTCmonitoring

   Los registros están ahora populando como se espera en tiempo real y continuaremos monitoreando la aplicación.

4. August 27, 2026 at 9:57 PM UTCresolved

   El problema se ha resuelto y los registros están populando como se espera.

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

1. August 25, 2026 at 9:41 AM UTCidentified

   Hemos identificado un problema que afecta a la función de Despliegue de la Solución en Studio Web en la región del Japón, donde los despliegues de soluciones pueden fracasar. Se ha preparado una solución y se publicará en breve. Proporcionaremos más actualizaciones a medida que se disponga de más información.

2. August 25, 2026 at 9:47 AM UTCmonitoring

   La solución se ha desplegado con éxito en la región del Japón y la cuestión ha sido mitigada. Estamos monitoreando estrechamente el servicio para asegurar que el Despliegue de la Solución siga funcionando según lo previsto y proporcionará nuevas actualizaciones según sea necesario.

3. August 25, 2026 at 10:12 AM UTCresolved

   El problema se ha resuelto, y el despliegue de solución en Studio Web funciona como se espera en la región del Japón. No se ha observado ningún nuevo impacto.

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

1. August 25, 2026 at 3:58 AM UTCinvestigating

   Estamos investigando un problema que afecta a los clientes usando Insights en la región de Singapur, donde los paneles pueden no cargar y mostrar errores de timeout. Nuestros equipos están trabajando para identificar la causa raíz y proporcionarán nuevas actualizaciones a medida que se disponga de más información.

2. August 25, 2026 at 4:37 AM UTCmonitoring

   La cuestión ha sido mitigada, y estamos monitoreando estrechamente el servicio Insights en la región de Singapur para asegurar que los paneles sigan cargando según lo previsto.

3. August 25, 2026 at 4:53 AM UTCresolved

   La cuestión se ha resuelto y el servicio Insights en la región de Singapur funciona según lo previsto. No se ha observado ningún nuevo impacto.

4. September 4, 2026 at 11:46 AM UTCpostmortem

   ## Impacto del cliente Entre el 25 de agosto de 2026 a las 3:42 de la UTC y el 25 de agosto de 2026 a las 4:53 de la UTC, los clientes que utilizaban Insights en la región de Singapur experimentaron fallos cargando los tableros Insights. Los usuarios afectados vieron las páginas dashboard tiempo fuera o no se carga, y se observaron errores del servidor para solicitudes de servicio relacionadas. El impacto primario fue en el acceso de tableros insights, incluyendo gráficos y alertas. Un servicio de backend relacionado también devolvió errores del servidor durante el incidente, pero el acceso de dashboard se había recuperado antes de la resolución final. ## Root cause El incidente se atribuyó a una interrupción regional del servicio de Microsoft en Singapur que afectaba a la infraestructura utilizada por el servicio Insights. Durante la interrupción, el servicio Insights no pudo atender de forma fiable las solicitudes de dashboard, lo que dio lugar a tiempo de solicitud y errores del servidor. No se hicieron cambios de nuestro lado. El servicio se recuperó a medida que se resolvió la perturbación regional de Microsoft, y Microsoft informó posteriormente una cuestión de servicio regional de Singapur en su página de estado. Se ha solicitado a Microsoft un análisis formal de causas raíz para confirmar el mecanismo de fallo específico e identificar cualquier medida preventiva o de mitigación adicional. ## Detection El monitoreo de salud automatizado para el servicio Insights detectó el problema el 25 de agosto de 2026 a las 3:42 am UTC. El impacto del cliente se confirmó en el puente de respuesta poco después de la detección. ## Response Al 25 de agosto de 2026 a las 3:58 am UTC, publicamos una actualización del estado público señalando que los paneles Insights en la región de Singapur podrían no cargar y mostrar errores de timeout. Durante la respuesta, nuestro equipo de ingeniería verificó errores de servidor en monitoreo automatizado, intentó acceder al diagnóstico de servicio, y comenzó un procedimiento de recuperación en la infraestructura subyacente. Al 25 de agosto de 2026 a las 4:01 am UTC, el servicio Insights se recuperó mientras el procedimiento de recuperación estaba en marcha, y la carga de dashboard fue validada en varias cuentas de prueba. Al 25 de agosto de 2026 a las 4:37 am UTC, trasladamos el incidente a monitorear después de confirmar los paneles cargados con éxito. Un servicio de backend relacionado se recuperó el 25 de agosto de 2026 a las 4:49 am UTC, y el incidente fue marcado el 25 de agosto de 2026 a las 4:53 am UTC. ## Follow up 1. Solicitar un análisis de causa raíz de Microsoft para la perturbación regional de Singapur que afecte el problema de carga de paneles de información.

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

1. August 25, 2026 at 3:44 AM UTCinvestigating

   Estamos investigando un problema que afecta a los clientes utilizando la funcionalidad Extended OCR en el servicio de Entendimiento de Documentos en la región de Singapur. Nuestros equipos están trabajando para identificar la causa raíz y proporcionarán nuevas actualizaciones a medida que se disponga de más información.

2. August 25, 2026 at 4:04 AM UTCmonitoring

   La cuestión ha sido mitigada, y estamos monitoreando estrechamente el servicio para asegurar que siga funcionando según lo previsto. Proporcionaremos más actualizaciones a medida que se disponga de más información.

3. August 25, 2026 at 4:59 AM UTCresolved

   La cuestión se ha resuelto y el servicio funciona según lo previsto. No se ha observado ningún nuevo impacto.

4. August 27, 2026 at 3:42 AM UTCpostmortem

   ## Impacto del cliente On August 25, 2026, Extended OCR requests in the Document Understanding service failed with 500 status code in the Singapore region for approximately 33 minutes, between 03:08 and 03:41 UTC. La causa fue una interrupción del servicio regional de Microsoft en Singapur. Toda otra funcionalidad de Entendimiento de Documentos no fue afectada, y ninguna otra región fue impactada. ## Root cause El fracaso se atribuyó a una interrupción regional del servicio de Microsoft en Singapur que afectaba a los recursos utilizados por la capacidad ampliada de OCR. No se habían producido cambios a nuestro lado, y Microsoft posteriormente actualizó su propia página de estado para reflejar un problema regional de Singapur. Se ha solicitado un análisis formal de causa raíz de Microsoft. ## Detection Una alerta automatizada para el servicio de Entendimiento de Documentos disparó el 25 de agosto de 2026 a las 3:13 am UTC. The alert was acknowledged promptly, and the incident was declared customer-impacting within minutes. ## Response El ingeniero de guardia encargó el impacto a la región de Singapur. Los demandados descartaron una actualización reciente de servicios como la causa, ya que la misma actualización se había desplegado en otras regiones sin ningún impacto comparable, lo que señaló un fracaso de dependencia regional fuera de nuestra infraestructura. Debido a que el fallo se originó en un servicio de Microsoft, ninguna acción atenuante estaba disponible o requerida en el lado UiPath. Las solicitudes comenzaron a tener éxito de nuevo a las 03:41 UTC mientras se recuperaba la dependencia de Microsoft. Los encuestados mantuvieron el incidente abierto para verificar la recuperación sostenida: diez minutos de tráfico limpio fueron confirmados a las 03:51 UTC, el incidente se trasladó a Monitoreo a las 04:04 UTC, y se resolvió a las 04:59 UTC después de la estabilidad continua sin más fallos. ## Follow up 1. Pidió un análisis de las causas profundas de Microsoft para la perturbación regional de Singapur que afectaba a las dependencias de OCR ampliadas, incluida la forma en que se puede prevenir la recurrencia.

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

1. August 24, 2026 at 10:43 AM UTCidentified

   Hemos identificado la causa de un problema que impacta a un pequeño número de clientes utilizando UiPath Apps autorizados por el servicio Studio Web en varias regiones. Nuestros equipos están listos con una solución, y el despliegue está a punto de comenzar en las regiones afectadas. Seguiremos vigilando el despliegue y proporcionaremos nuevas actualizaciones a medida que la solución surta efecto.

2. August 24, 2026 at 11:30 AM UTCmonitoring

   La solución ha sido implementada con éxito en todas las regiones afectadas, y la cuestión ha sido mitigada. Estamos monitoreando de cerca el servicio para asegurar que la solución siga funcionando como se espera y proporcionará nuevas actualizaciones según sea necesario.

3. August 24, 2026 at 11:55 AM UTCresolved

   La cuestión se ha resuelto y el servicio funciona según lo previsto. No se ha observado ningún nuevo impacto.

4. September 1, 2026 at 11:47 AM UTCpostmortem

   ## Impacto del cliente Entre el 19 de agosto de 2026 a las 2:33 pm UTC y el 24 de agosto de 2026 a las 11:30 am UTC, un subconjunto de clientes no pudo cargar proyectos UiPath Apps autorizados por Studio Web. Los clientes afectados experimentaron una total falta de disponibilidad de proyectos de aplicaciones en lugar de la lentitud o el rendimiento degradado. El impacto se limitó a un pequeño conjunto de clientes, cuyo servicio de aplicaciones fue hospedado en la región de Japón. La duración total de la intervención del cliente fue de aproximadamente 4 días y 21 horas. ## Root cause La causa raíz fue un desajuste de implementación entre Studio Web y UiPath Apps. El 19 de agosto de 2026, Studio Web recibió una actualización programada en la región de la UE que incluyó una actualización del marco. La actualización correspondiente de UiPath Apps que contenía la actualización del marco aún no se había desplegado en la unidad de escala de Japón. Una actualización anterior de las aplicaciones que ya era compatible con la nueva versión marco se había desplegado en todas las regiones excepto en el Japón, donde se había aplazado el despliegue debido a razones no relacionadas. Como resultado, la región de Japón seguía ejecutando una versión anterior de Apps que no era compatible con el Studio Web actualizado. ## Detection El problema fue reportado por un cliente a través de su equipo de cuenta UiPath el 24 de agosto de 2026 a las 9:36 am UTC. An incident was opened at 10:21 am UTC, and a public status page incident was declared within a minute. El monitoreo automatizado existente no detectó el problema porque valida combinaciones de despliegue coincidentes; mejorar la detección para configuraciones mixtas es parte de nuestro plan de seguimiento. ## Response A pocos minutos de abrir el incidente, identificamos el desajuste de implementación como la causa raíz y decidimos acelerar el despliegue de la correspondiente actualización de UiPath Apps a todas las regiones afectadas, alineando aplicaciones con la versión Studio Web ya servida para clientes impactados. A las 10:43 am UTC, publicamos una actualización del estado público confirmando la causa que se había identificado y que la solución estaba siendo implementada. A las 10:52 horas, se estaba llevando a cabo el despliegue de las regiones restantes, con varias regiones ya completas. A las 11:30 am UTC, confirmamos que la solución había sido desplegada en todas las regiones afectadas y marcó el incidente mitigado. A las 11.55 horas de la UTC, después de que la vigilancia no hubiera tenido más impacto, se resolvió el incidente. ## Follow up 1. Agregue alerta automática sobre telemetría de producción para detectar fallos de carga de aplicaciones correlacionados con la versión Studio Web que se sirve. 2. Implementar monitoreo sintético que carga regularmente un proyecto de aplicaciones de Studio Web a través de configuraciones de clientes representativas y alertas sobre fallo. 3. Ajustar secuenciación de lanzamiento para cambios de Studio Web y aplicaciones ajustados para que las actualizaciones de aplicaciones dependientes estén completamente desplegadas en todas las regiones antes de que la nueva experiencia Studio Web llegue al tráfico de clientes.

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

1. August 21, 2026 at 12:37 PM UTCmonitoring

   Se ha aplicado una solución para la cuestión que afecta a la clasificación y extracción de documentos para la comprensión de documentos en Estados Unidos, y actualmente estamos monitoreando los resultados.

2. August 21, 2026 at 1:36 PM UTCresolved

   Se ha resuelto la cuestión de la clasificación y extracción de documentos para la comprensión de documentos en la región de los Estados Unidos. Tras un período de vigilancia, el servicio se confirma saludable y funciona normalmente.

3. August 27, 2026 at 3:46 AM UTCpostmortem

   ## Impacto del cliente Entre el 21 de agosto de 2026 a las 11:05 am UTC y el 21 de agosto de 2026 a las 12:18 pm UTC, un subconjunto de clientes experimentó operaciones fallidas de Entendimiento de Documentos, incluyendo clasificación de documentos, extracción y digitalización. La duración estimada del desembolso parcial fue de 48 minutos. El impacto se limitó a los clientes usando el Entendimiento de Documentos en la región de Estados Unidos. ## Root cause The incident was caused by the Document Understanding storage database failover settings entering a broken state during a preventive database scale-up operation. La ampliación se inició después de que la base de datos se acercara a su límite de almacenamiento. Durante la operación, la base de datos secundaria no pudo ser escalada, el intento de eliminación de la configuración de fallos falló, y el proveedor de la base de datos tuvo que romper el enlace de replicación. Esto dejó la configuración de failover en un estado no disponible temporal, causando los servicios de almacenamiento y tiempo de funcionamiento que dependen de esa base de datos para fallar las solicitudes. ## Detection El incidente fue detectado a través de una alerta automatizada para los servicios de Entendimiento de Documentos, que fue reconocida el 21 de agosto de 2026 a las 12:10 pm UTC. ## Response Antes de que se declarara el incidente de impacto de los clientes, se completó la ampliación de la base de datos primaria y el apoyo del proveedor de la plataforma de base de datos se comprometió a la cuestión de la base de datos secundaria. Después de que la configuración de failover se rompió, exploramos la redirección de la conexión de servicio pero no pudimos identificar un camino seguro e inmediato para hacerlo dada la configuración actual del servicio. El servicio se restauró eliminando la base de datos secundaria poco saludable y recreando la configuración de failover. Para el 21 de agosto de 2026 a las 12:37 pm UTC, la solución había sido implementada y el monitoreo estaba en marcha. A las 1:36 pm UTC, el monitoreo confirmó que el servicio era saludable, y el incidente fue marcado resuelto. ## Follow up 1. Solicitar un análisis de causa raíz del proveedor de la plataforma de base de datos para determinar por qué la base de datos secundaria no se puede escalar y por qué la remediación de configuración de fallos requiere replicación de ruptura. 2. Actualizar los umbrales de almacenamiento de la base de datos y el enrutamiento para que las alertas se asignen y actúen con anterioridad, incluyendo una advertencia de menor duración al 75% de uso y una alerta de mayor intensidad al 85% de uso.

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

1. August 19, 2026 at 4:34 PM UTCinvestigating

   Estamos investigando un problema que puede afectar a algunos clientes usando Claude Sonnet 4.6 en Agentes en la región de Estados Unidos. Nuestro equipo de ingeniería está trabajando activamente para entender el problema y compartirá nuevas actualizaciones a medida que se disponga de más información.

2. August 19, 2026 at 4:40 PM UTCmonitoring

   Hemos mitigado la cuestión. Nuestro equipo de ingeniería está activo por la mañana y compartirá nuevas actualizaciones a medida que se disponga de más información.

3. August 19, 2026 at 4:42 PM UTCmonitoring

   Hemos mitigado la cuestión. Nuestro equipo de ingeniería está monitoreando activamente y compartirá nuevas actualizaciones a medida que se disponga de más información.

4. August 19, 2026 at 4:55 PM UTCresolved

   La cuestión se ha resuelto.

5. August 31, 2026 at 12:41 PM UTCpostmortem

   ## Impacto del cliente Entre el 19 de agosto de 2026 a las 1:36 pm UTC y el 19 de agosto de 2026 a las 3:53 pm UTC, un subconjunto de clientes recibió errores al utilizar Claude Sonnet 4.6 en Agentes. El impacto duró aproximadamente 2 horas y 17 minutos. El impacto fue para clientes usando Agentes en la región de Estados Unidos. También se observaron errores en Claude Opus 4.6 y Claude Opus 4.5, que se utilizan en menor volumen. -... ## Root Cause Como parte de una migración de infraestructura planeada, movimos el servicio de plataforma que recorre las solicitudes modelo de Agentes en un nuevo sistema de entrega de configuración, región por región. La nueva fuente de configuración perdió las entradas de enrutamiento de tres modelos Claude Sonnet 4.6, Claude Opus 4.6, y Claude Opus 4.5. Sin esas entradas, el servicio no pudo resolver un destino válido para las solicitudes a esos modelos, y los rechazó con errores. Otros modelos no se vieron afectados y continuaron sirviendo normalmente a lo largo de todo. -... ## Detection El problema fue detectado a través de escaladas de clientes el 19 de agosto de 2026 a las 2:55 pm UTC — aproximadamente 1 hora y 19 minutos después de la primera solicitud afectada. Nuestro equipo de ingeniería abordó el tema a modelos específicos de Claude y comenzó la investigación. La comunicación pública comenzó a las 3:08 pm UTC. Nuestro monitoreo de alerta se basa en índices de error agregados. Aunque casi todas las solicitudes a los tres modelos afectados estaban fallando, esos modelos representaban una pequeña parte del tráfico general en la región, por lo que la señal agregada no cruzó nuestros umbrales de alerta y la cuestión no se planteó automáticamente. Esta es la brecha de detección abordada en el seguimiento que figura a continuación. -... ## Response A las 3:25 pm UTC, la fuente de configuración incompleta fue identificada como la causa, y se inició una solución. A las 3:47 pm UTC, el despliegue de la solución estaba en marcha, y el servicio se monitoreó activamente a medida que se produjo el cambio. A las 3:59 pm UTC, los registros de servicio confirmaron que el problema fue mitigado, y a las 4:00 pm UTC la tasa de fracaso fue confirmada al 0%. El incidente fue marcado mitigado a las 4:40 pm UTC, y la resolución completa fue declarada a las 4:55 pm UTC después de la vigilancia continua y la confirmación del cliente de que el servicio estaba trabajando como se esperaba. -... ## Follow-Up La migración de infraestructura se ha completado en todas las regiones y la configuración de enrutamiento ahora se basa en una única fuente, eliminando el desajuste que causó este incidente para que no pueda repetirse. Se están introduciendo controles automáticos para verificar continuamente cada modelo soportado en cada región, por lo que se detecta y alerta inmediatamente un modelo no disponible, incluso en regiones de menor tráfico.

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

1. August 18, 2026 at 5:54 PM UTCinvestigating

   Estamos investigando informes de un outage que impacta las fallas en las evaluaciones de expresión relacionadas con los parámetros de producción de tareas HITL para Asgentic Orchestratron en usuarios comunitarios en Europa. Impacto: Los usuarios pueden ser incapaces de completar las tareas de 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. August 18, 2026 at 8:31 PM UTCidentified

   Hemos identificado la causa de una evaluación de la expresión que impacta el outage relacionada con los parámetros de producción de tareas HITL para la Orquesta Agentic en usuarios comunitarios en Europa. Impacto: Los usuarios experimentarán fallos cuando tengan expresiones usando el parámetro de salida de 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.

3. August 18, 2026 at 9:45 PM UTCidentified

   Hemos identificado la solución y la resolución está en marcha. Siguiente actualización: Nuestros equipos están trabajando en la solución y compartirán las actualizaciones disponibles.

4. August 18, 2026 at 10:53 PM UTCmonitoring

   Hemos desplegado la solución y estamos monitoreando la resolución. Siguiente actualización: Nuestros equipos están monitoreando la resolución y compartirán las actualizaciones disponibles.

5. August 18, 2026 at 11:25 PM UTCresolved

   La salida se ha resuelto y la Orquesta Agentic está en pleno funcionamiento. Impacto: No hay impacto continuo del usuario.

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

1. August 18, 2026 at 12:08 PM UTCidentified

   Hemos identificado la causa raíz de un problema en Studio Web donde la pantalla de configuración de recursos para cambiar los atributos de recursos no está cargando. Estamos implementando una solución.

2. August 18, 2026 at 1:05 PM UTCidentified

   El despliegue de la solución está en marcha. Proporcionaremos más actualizaciones a medida que avance el despliegue.

3. August 18, 2026 at 2:06 PM UTCidentified

   La solución ha sido verificada y se está distribuyendo en todas las regiones restantes. Estamos monitoreando el despliegue y la recuperación. Gracias por su paciencia.

4. August 18, 2026 at 5:03 PM UTCidentified

   El despliegue está progresando según lo previsto en las demás regiones. Seguimos vigilando el despliegue. Gracias por su paciencia.

5. August 18, 2026 at 6:12 PM UTCmonitoring

   El despliegue está progresando según lo previsto en las demás regiones. Seguimos vigilando el despliegue. Gracias por su paciencia.

6. August 18, 2026 at 7:05 PM UTCresolved

   La lista se completa y la cuestión debe resolverse.

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

1. August 18, 2026 at 5:32 AM UTCinvestigating

   Estamos investigando un problema que afecta a las cuentas comunitarias donde las entidades recién creadas pueden tardar aproximadamente una hora en aparecer en Studio Web. No se pierden datos y las entidades existentes no se ven afectadas.

2. August 18, 2026 at 6:48 AM UTCinvestigating

   Seguimos investigando la cuestión y estamos trabajando para identificar la causa raíz y restaurar los tiempos normales de procesamiento.

3. August 18, 2026 at 8:44 AM UTCinvestigating

   Seguimos investigando la cuestión que afecta a un subconjunto de inquilinos en Europa, Estados Unidos y Japón, donde las entidades recién creadas pueden tardar más de lo esperado en aparecer en Studio Web. No se pierden datos y las entidades existentes no se ven afectadas.

4. August 18, 2026 at 9:37 AM UTCidentified

   Hemos identificado la causa y estamos trabajando en una resolución para la cuestión que afecta a un subconjunto de inquilinos en Europa, Estados Unidos y Japón. Gracias por su paciencia.

5. August 18, 2026 at 11:19 AM UTCmonitoring

   La cuestión ha sido mitigada y esperamos que los plazos de procesamiento vuelvan a la normalidad en breve. Estamos monitoreando la recuperación de cerca. Gracias por su paciencia.

6. August 18, 2026 at 11:57 AM UTCresolved

   La cuestión se ha resuelto y el tiempo de procesamiento ha vuelto a la normalidad. Gracias por su paciencia.

7. August 27, 2026 at 3:51 AM UTCpostmortem

   ## Impacto del cliente Entre el 18 de agosto de 2026 a las 5:11 am UTC y el 18 de agosto de 2026 a las 11:57 am UTC, las entidades recién creadas en un subconjunto de los inquilinos UiPath Cloud podrían tardar más de lo esperado para aparecer en Studio Web. At the time of initial assessment, newly created entities were appearing with an approximately one-hour delay. Los clientes de Europa, Estados Unidos y Japón se vieron afectados. La propia creación de Entidades continuó con éxito, no se perdieron datos y las entidades existentes no se vieron afectadas. ## Root cause La cuestión se debió a un volumen inusualmente elevado de solicitudes de creación de activos de un inquilino. Esas solicitudes generaron más eventos que nuestro servicio de indexación de entidades backend podría procesar al mismo ritmo, creando un atraso en la cola de procesamiento de eventos. Debido a que Studio Web confía en este servicio para mostrar entidades creadas recientemente, las nuevas entidades aparecieron sólo después de que se procesara el atraso. ## Detection El tema fue identificado por nuestro equipo de ingeniería por entidad procesando alerta de latencia, y un incidente fue declarado a las 5:11 am UTC el 18 de agosto de 2026. A las 5:23 am UTC, el análisis confirmó que la última entidad procesada estaba aproximadamente una hora detrás. ## Response A las 5:32 am UTC, hemos publicado una actualización inicial del cliente notando la visibilidad retardada de las entidades creadas recientemente en Studio Web. Para las 6:07 am UTC, la investigación identificó tráfico inusualmente alto de creación de activos de un inquilino, y a las 7:03 am UTC, ajustamos los recursos de base para el servicio afectado para ayudar a procesar la recuperación. A las 7:59 am UTC, la fuente del volumen de alta solicitud había dejado de enviar solicitudes, y la cola comenzó a drenar. A las 9:59 am UTC, comenzamos un proceso de sincronización de datos para el arrendatario afectado, y a las 10:31 am UTC, eliminamos los eventos problemáticos apagados para que el procesamiento normal pudiera alcanzar más rápido. La profundidad de las colas disminuyó de 95.000 artículos a las 8:34 a 1.000 artículos a las 11:44 horas. El incidente fue marcado mitigado a las 11:19 am UTC después de que el procesamiento se recuperó sustancialmente, y resolvió a las 11:57 am UTC después del tiempo de procesamiento devuelto a la normalidad. ## Follow up Recortar la sincronización de datos para el arrendatario afectado y monitorear la ingestión hasta que los datos del arrendatario se confirmen consistentes. Mejorar el manejo de la entidad en el backend de indexación para que el atraso no se apile a este ritmo.

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

1. August 14, 2026 at 9:24 PM UTCidentified

   We have identified the cause of the degraded performance impacting Orchestrator in US region and are working on mitigation. Impact: Users may experience delayed loads and views on Orchestrator Robot logs. Additional updates will be provided as we move toward resolution.

2. August 14, 2026 at 11:22 PM UTCresolved

   The issue has been resolved and Orchestrator Robot logs performance has returned to expected levels after degraded performance impacted Robot logs to load in US region. Impact: No ongoing user impact.

3. August 28, 2026 at 4:55 PM UTCpostmortem

   ## Customer impact Between August 14, 2026 at 8:54 pm UTC and August 15, 2026 at 2:09 AM UTC, a subset of customers in the US region experienced significant slowness in the Orchestrator Jobs and Logs pages, and robot logs appeared later than expected in the logs view. Performance had substantially recovered by 11:22 PM UTC on August 14, with full recovery confirmed with affected customers at 2:09 AM UTC on August 15. Automation execution was not affected, jobs continued to be scheduled and to run normally throughout. No log data was lost. Logs continued to be recorded and became visible once the system caught up. Requests did not fail, so no errors were surfaced, pages were slow to load and recent activity appeared missing or delayed. No other region was impacted. ## Root cause Orchestrator stores and retrieves robot logs using a dedicated search and storage system. Routine maintenance on that system causes data to be redistributed internally across the cluster. Our analysis indicates that a redistribution larger than anticipated consumed capacity that would otherwise have served customer requests, slowing both the retrieval of existing logs and the processing of new ones. This accounts for the majority, but not the entirety, of the slowdown observed, and analysis of the remaining contributing factor is continuing. Capacity returned to normal without intervention, at which point log visibility and page performance recovered. ## Detection The issue was surfaced through customer reports of slow Jobs and Logs pages in the US region. ## Response We posted a status update confirming that we were investigating degraded Orchestrator performance in the US region. Our engineering team scoped the impact to the US region and narrowed the slowdown to the log storage and search layer. The degradation stemmed from capacity contention that eased as the redistribution completed, and responders monitored the system through recovery. Page performance and log visibility returned to expected levels over the course of the evening, and recovery was subsequently confirmed with affected customers at 2:09 AM UTC on August 15. ## Follow up 1. We are adding monitoring and alerting on the response times customers experience and on the delay between a robot log being generated and becoming visible, so that degradation of this kind is detected proactively. 2. We are documenting an operational procedure that gives our on-call engineers defined steps to reduce customer impact during this class of degradation. 3. We are changing how routine maintenance on the log storage system is scheduled and paced in the US region so that it does not affect customer-facing performance. 4. We are increasing spare capacity in the log storage system so that internal data movement has room to complete without competing with customer requests.

1. August 18, 2026 at 10:58 AM UTCresolved

   Una tormenta de solicitudes en una característica de modelo raramente usada en IXP Communications Mining causó un bucle de retry para bloquear las solicitudes sincronizadas en la API IXP más amplia. Esto causó solicitudes para fracasar con 500's ya que los trabajadores estaban ocupados con solicitudes de larga duración. El escalado automático alcanzó rápidamente su máxima capacidad y la resolución se hizo sólo mediante la aplicación de una fijación de código que introdujo plazos estrictos a la solicitud de API que contribuye. La tormenta de solicitud comenzó alrededor de 15:10 UTC y detectó una 15:15 UTC por alarmas automáticas. La resolución fue confirmada alrededor de 18:15 UTC. El incidente se atribuyó inicialmente erróneamente a sólo el cliente haciendo la tormenta de solicitudes, pero fue descubierto después que impactó a una gama más amplia de usuarios. Impacto total limitado a un puñado de usuarios en Estados Unidos.

2. August 18, 2026 at 9:25 PM UTCpostmortem

   ## Impacto del cliente El 12 de agosto de 2026, entre aproximadamente 15:10 y 18:15 UTC, los usuarios de Communications Mining (IXP) en la región de los Estados Unidos experimentaron fallos de solicitud intermitente. El incidente se limitó a una de las unidades de despliegue de la región, donde los usuarios de ella vieron fallos en ráfagas de cinco a diez minutos, con hasta el 5–7% de sus solicitudes fallando con errores de 5xx en el pico. Entre ráfagas el servicio funcionaba normalmente, las solicitudes retrigidas generalmente tuvieron éxito, y no se perdieron datos. ## Root Cause Una tormenta de solicitudes a una característica de API raramente usada que compute las predicciones de aprendizaje automático a la demanda coincidió con la repetida reentrenamiento del modelo solicitado. Cada reentrenamiento invalida las predicciones de caché, convirtiendo cada solicitud en una computación de varios minutos. La API no colocó ningún límite de tiempo en cuanto una solicitud podría esperar a este cálculo, por lo que estas solicitudes de larga duración ocuparon progresivamente toda la capacidad de procesamiento de solicitudes, causando que las solicitudes no relacionadas fallaran. El escalado automático alcanzó su máxima capacidad rápidamente y no pudo compensar. ## Detection El monitoreo automatizado detectó los fallos a las 15:15 UTC, unos cinco minutos después del inicio del impacto, y llamó al ingeniero en la cabina. El incidente se atribuyó inicialmente sólo al cliente generando la tormenta de solicitud, pero los informes del cliente y la investigación posterior mostraron que un conjunto más amplio de usuarios se vio afectado durante las ráfagas de fallo. ## Response El ingeniero rastreó los fracasos de la espera sin límites en el camino de predicción a pedido. La capacidad de servicio se restauró repetidamente mediante la sustitución automática de instancias, mientras que se elaboró una solución de código. La solución es un plazo estricto para la solicitud de contribución, por lo que falla rápidamente sin afectar otras solicitudes, y se desplegó en la región afectada aproximadamente a las 18:00 UTC, y la resolución fue confirmada a las 18:15 UTC. ## Follow-Up 1. El estricto cronograma y la fijación de carga se ha hecho permanente y liberado a todas las regiones (completo el 13 de agosto de 2026). 2. Evaluar los límites por cliente en el cálculo de predicción a demanda para que el uso de un solo cliente no pueda degradar la API compartida.

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

1. August 10, 2026 at 2:11 PM UTCinvestigating

   Estamos investigando el desempeño degradado que impacta a los Servicios Front-End en el Entendimiento de Documentos en la Región Este de GXP. Impacto: Los usuarios pueden notar los plazos al acceder a la UI en GXP US. Siguiente actualización: Se proporcionarán actualizaciones adicionales a medida que se disponga de más información.

2. August 10, 2026 at 2:25 PM UTCresolved

   La cuestión se ha resuelto y el desempeño del Servicio Front-End en el Entendimiento de Documentos ha regresado a los niveles esperados después de que el rendimiento degradado impactó a la UI en la Región Este de los Estados Unidos. Impacto: No hay impacto continuo del usuario.

3. August 19, 2026 at 6:14 AM UTCpostmortem

   ## Impacto del cliente Entre el 10 de agosto de 2026 a las 13:21 UTC y el 10 de agosto de 2026 a las 14:03 UTC, un subconjunto de clientes experimentó un rendimiento y un tiempo degradados al acceder a la interfaz de usuario de Document Understanding, que proporciona la experiencia de diseño en la región de los Estados Unidos retrasados. Las automatizaciones de procesamiento de documentos no se vieron afectadas. ## Root cause Durante un despliegue manual de una construcción preexistente del servicio detrás de la interfaz de usuario de Document Understanding a la región de Estados Unidos retrasada, nuestro proceso de implementación reasignó el identificador de la versión para el servicio que se está implementando. La interfaz de Entendimiento de Documentos requiere que sus recursos de apoyo estén disponibles bajo el mismo identificador de versión que el servicio desplegado. Debido a que el proceso de implementación cambió este identificador, la interfaz no pudo localizar los recursos necesarios, causando que se volviera inaccesible o fuera de tiempo. ## Detection Nos dimos cuenta de la cuestión momentos después de que se terminó el despliegue, mediante la verificación manual como parte de la lista de verificación de despliegue manual. Una alerta automatizada siguió en breve, disparada a las 13:28 UTC el 10 de agosto de 2026. ## Response Después de identificar la razón para el fracaso del despliegue manual, nuestro equipo de ingeniería comenzó a desplegar una actualización corregida con los recursos necesarios disponibles. Al mismo tiempo, el equipo de operaciones se comprometió a realizar un rebote manual del despliegue. El retroceso se completó a las 14:03 UTC, restaurando el acceso a la experiencia de diseño. A las 14:11 UTC, publicamos una actualización de estado público que indica el rendimiento degradado y los posibles timeouts en la interfaz de usuario de Document Understanding para la región de Estados Unidos retrasada. Para 14:15 UTC, la actualización corregida había finalizado y la interfaz fue confirmada como implementada con una versión y trabajo correctos. At 14:25 UTC, the incident was marked resolved and the public status page was updated to confirm that Document Understanding interface performance had returned to expected levels. ## Follow up 1. Estamos reduciendo el tiempo necesario para restaurar una versión anterior del servicio, de modo que la recuperación de un despliegue fallido sea más rápida. 2. Estamos haciendo mejoras en el proceso de despliegue manual para prevenir una situación futura, validando la existencia de los recursos necesarios como requisito previo.

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

1. August 8, 2026 at 11:54 AM UTCidentified

   We have identified the cause of the outage impacting Uipath Apps is facing outage in Delayed US region and are working on a fix. Impact: Users may continue to be unable to access Uipath Apps and solutions dependent on Uipath Apps. Team is working on service restoration.

2. August 8, 2026 at 1:01 PM UTCidentified

   Team is working on service restoration. We will update the status once mitigation is completed.

3. August 8, 2026 at 2:14 PM UTCidentified

   Team has identified an issue with an underlying resource and is actively working to restore service.

4. August 8, 2026 at 3:30 PM UTCidentified

   Team has made progress to fix underlying resource issue and is actively working to restore service.

5. August 8, 2026 at 3:32 PM UTCmonitoring

   Mitigation has been applied and performance is improving for the issue. We are monitoring closely to ensure stability.

6. August 8, 2026 at 4:01 PM UTCresolved

   The mitigation has remained stable, and performance has returned to expected levels. We have confirmed service restoration for UiPath Apps in the Delayed US region and are marking this incident as resolved.

7. August 12, 2026 at 10:14 AM UTCpostmortem

   ## Customer impact Between 11:20 am UTC and 2:54 pm UTC on August 8, 2026, a subset of customers in the Delayed US region experienced failures accessing UiPath Apps and solutions that depend on UiPath Apps. Customers may have seen UiPath Apps unavailable or intermittent request failures. The impact lasted approximately 3 hours and 34 minutes. ## Root cause The incident was caused by database connection saturation following scheduled maintenance performed by our database provider. As application services scaled up, they created additional database connections, which caused new connection attempts to fail and resulted in connection reset errors in UiPath Apps. ## Detection Automated alerts detected the issue at 11:24 am UTC on August 8, 2026. Application telemetry showed failures beginning at approximately 11:20 am UTC. ## Response At 11:00 am UTC, scheduled maintenance began automatically. At 11:20 am UTC, requests began failing. At 11:24 am UTC, automated alerts were triggered, and the team began investigating. At 12:24 pm UTC, database capacity was scaled up as a mitigation. At 1:13 pm UTC, application services were restarted to reduce saturated connection usage and refresh database connections. Connection levels remained elevated, and the database automatically scaled at 1:22 pm UTC and at 2:36 pm UTC. Following these mitigation efforts, request failures stopped at 2:54 pm UTC. At 3:33 pm UTC, the mitigation was confirmed to be stable, and performance was improving. Full recovery was confirmed at 4:01 pm UTC after performance returned to expected levels. ## Follow up 1. Obtain and review the database provider's root cause analysis explaining what caused the connection issue following their maintenance activity. 2. Implement an application-side limit on database connection creation to prevent connection saturation. 3. We are reviewing the automatic scaling behavior that amplified connection volume during the incident and address any contributing factors.

1. August 6, 2026 at 9:14 PM UTCresolved

   Between 06-08-2026 10:00 UTC and 06-08-2026 13:00 UTC, some organizations in the US region were unable to complete document ingestion. A small number of search requests in the same region were also slow or timed out. The issue was caused by a capacity constraint affecting ingestion processing in US. Normal performance was restored at 13:00 UTC. We have monitored the affected environments since recovery and confirm the issue is fully mitigated. Ingestion requests that failed during this window were not retried automatically and will need to be re-submitted. No action is required for search.

2. August 13, 2026 at 3:12 PM UTCpostmortem

   ## Customer impact Between August 6, 2026 at 10:00 am UTC and 1:00 pm UTC, some organizations in the US region were unable to complete document ingestion in **UiPath Context Grounding**. A small number of search requests in the same region were also slow or timed out. **Action required:** please re-submit the affected ingestion requests. Ingestion retries a failing request automatically for a limited number of attempts. Once those attempts are exhausted the request is marked failed and is not retried again, so affected documents will not appear in your index until the request is submitted again. Failed requests are listed in the ingestion history for each index. No action is required for search. Those requests were affected only while the issue was ongoing, and subsequent searches completed normally. --- ## Root cause A sudden increase in concurrent document ingestion triggered a high number of simultaneous document validation steps, which created a capacity bottleneck on the underlying infrastructure resource beyond its scaling capacity. Once that resource was saturated, ingestion operations began exceeding their time limits and failing. Automatic retries of the failed operations added further load, which sustained the condition. Search requests served by the same resource were delayed behind the same contention. --- ## Detection Automated alerts were flagged as the condition developed, and an automated infrastructure resource capacity alert triggered at 10:37 am UTC brought it to the team's attention. --- ## Response - **10:03 am UTC** — Automated low severity alerts started coming in. - **10:37 am UTC** — Automated alert for resource capacity issue paged the team. - **12:23 pm UTC** — As a mitigation step the impacted resource's capacity was increased. - **12:57 pm UTC** — Ingestion and search operations stopped failing and response times returned to normal. --- ## Follow-up - **The fix is deployed.** The validation step has been reimplemented to enforce the same limits at a small fraction of the previous cost, so this level of concurrent ingestion now sits well within available capacity. It was released to the affected US region on August 7, ahead of schedule, and reaches all remaining regions by early September. - **We are improving how quickly we detect issues like this.** We are adding monitoring that tracks whether document ingestion is completing successfully for customers, so problems are identified and acted on directly rather than inferred from underlying system alerts. This will be in place across all regions by the end of August.