Historial de interrupciones de Uipath

1. 3 de septiembre de 2026 a las 15:34 UTCinvestigating

   Actualmente estamos investigando el tema

2. 3 de septiembre de 2026 a las 15:39 UTCidentified

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

3. 3 de septiembre de 2026 a las 15:47 UTCmonitoring

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

4. 3 de septiembre de 2026 a las 16:17 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. 4 de septiembre de 2026 a las 17:48 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. 1 de septiembre de 2026 a las 13:49 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. 1 de septiembre de 2026 a las 14:07 UTCmonitoring

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

3. 1 de septiembre de 2026 a las 15:06 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. 31 de agosto de 2026 a las 16:55 UTCinvestigating

   Actualmente estamos investigando el tema.

2. 31 de agosto de 2026 a las 17:07 UTCidentified

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

3. 31 de agosto de 2026 a las 18:24 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. 31 de agosto de 2026 a las 19:39 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. 28 de agosto de 2026 a las 15:41 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. 28 de agosto de 2026 a las 17:27 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. 28 de agosto de 2026 a las 17:39 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. 28 de agosto de 2026 a las 20:00 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. 28 de agosto de 2026 a las 22:57 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. 3 de septiembre de 2026 a las 8:49 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. 27 de agosto de 2026 a las 17:16 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. 27 de agosto de 2026 a las 18:53 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. 27 de agosto de 2026 a las 20:31 UTCmonitoring

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

4. 27 de agosto de 2026 a las 21:57 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. 25 de agosto de 2026 a las 9:41 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. 25 de agosto de 2026 a las 9:47 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. 25 de agosto de 2026 a las 10:12 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. 25 de agosto de 2026 a las 3:58 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. 25 de agosto de 2026 a las 4:37 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. 25 de agosto de 2026 a las 4:53 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. 4 de septiembre de 2026 a las 11:46 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. 25 de agosto de 2026 a las 3:44 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. 25 de agosto de 2026 a las 4:04 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. 25 de agosto de 2026 a las 4:59 UTCresolved

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

4. 27 de agosto de 2026 a las 3:42 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. 24 de agosto de 2026 a las 10:43 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. 24 de agosto de 2026 a las 11:30 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. 24 de agosto de 2026 a las 11:55 UTCresolved

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

4. 1 de septiembre de 2026 a las 11:47 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. 21 de agosto de 2026 a las 12:37 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. 21 de agosto de 2026 a las 13:36 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. 27 de agosto de 2026 a las 3:46 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. 19 de agosto de 2026 a las 16:34 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. 19 de agosto de 2026 a las 16:40 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. 19 de agosto de 2026 a las 16:42 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. 19 de agosto de 2026 a las 16:55 UTCresolved

   La cuestión se ha resuelto.

5. 31 de agosto de 2026 a las 12:41 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. 18 de agosto de 2026 a las 17:54 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. 18 de agosto de 2026 a las 20:31 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. 18 de agosto de 2026 a las 21:45 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. 18 de agosto de 2026 a las 22:53 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. 18 de agosto de 2026 a las 23:25 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. 18 de agosto de 2026 a las 12:08 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. 18 de agosto de 2026 a las 13:05 UTCidentified

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

3. 18 de agosto de 2026 a las 14:06 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. 18 de agosto de 2026 a las 17:03 UTCidentified

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

5. 18 de agosto de 2026 a las 18:12 UTCmonitoring

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

6. 18 de agosto de 2026 a las 19:05 UTCresolved

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

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

1. 18 de agosto de 2026 a las 5:32 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. 18 de agosto de 2026 a las 6:48 UTCinvestigating

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

3. 18 de agosto de 2026 a las 8:44 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. 18 de agosto de 2026 a las 9:37 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. 18 de agosto de 2026 a las 11:19 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. 18 de agosto de 2026 a las 11:57 UTCresolved

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

7. 27 de agosto de 2026 a las 3:51 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. 14 de agosto de 2026 a las 21:24 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. 14 de agosto de 2026 a las 23:22 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. 28 de agosto de 2026 a las 16:55 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. 18 de agosto de 2026 a las 10:58 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. 18 de agosto de 2026 a las 21:25 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. 10 de agosto de 2026 a las 14:11 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. 10 de agosto de 2026 a las 14:25 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. 19 de agosto de 2026 a las 6:14 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. 8 de agosto de 2026 a las 11:54 UTCidentified

   Hemos identificado la causa de la salida que impacta las aplicaciones de Uipath se enfrenta a la superación en la región de EE.UU. retrasada y están trabajando en una solución. Impacto: Los usuarios pueden seguir siendo incapaces de acceder a las aplicaciones y soluciones Uipath dependientes de Uipath Apps. El equipo está trabajando en la restauración del servicio.

2. 8 de agosto de 2026 a las 13:01 UTCidentified

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

3. 8 de agosto de 2026 a las 14:14 UTCidentified

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

4. 8 de agosto de 2026 a las 15:30 UTCidentified

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

5. 8 de agosto de 2026 a las 15:32 UTCmonitoring

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

6. 8 de agosto de 2026 a las 16:01 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. 12 de agosto de 2026 a las 10:14 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.

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

1. 6 de agosto de 2026 a las 21:14 UTCresolved

   Entre 06-08-2026 10:00 UTC y 06-08-2026 13:00 UTC, algunas organizaciones de la región de Estados Unidos no pudieron completar la ingestión de documentos. Un pequeño número de solicitudes de búsqueda en la misma región también fueron lentas o programadas. El problema fue causado por una limitación de capacidad que afectó el procesamiento de la ingestión en Estados Unidos. El rendimiento normal fue restaurado a las 13:00 UTC. Hemos supervisado los entornos afectados desde que la recuperación y confirmamos que la cuestión se mitiga plenamente. Las solicitudes de ingestión que fallaron durante esta ventana no se retrataron automáticamente y tendrán que volver a presentar. No se requiere ninguna acción para la búsqueda.

2. 13 de agosto de 2026 a las 15:12 UTCpostmortem

   ## Impacto del cliente Entre el 6 de agosto de 2026 a las 10:00 am UTC y 1:00 pm UTC, algunas organizaciones de la región de Estados Unidos no pudieron completar la ingestión de documentos en **UiPath Context Grounding**. Un pequeño número de solicitudes de búsqueda en la misma región también fueron lentas o programadas. **Acción requerida:** Por favor vuelva a presentar las solicitudes de ingestión afectadas. La ingestión retrata una solicitud de fallo automáticamente para un número limitado de intentos. Una vez agotados los intentos, la solicitud está marcada y no se vuelve a recortar, por lo que los documentos afectados no aparecerán en su índice hasta que la solicitud sea presentada de nuevo. Las solicitudes fallidas se enumeran en el historial de ingestión para cada índice. No se requiere ninguna acción para la búsqueda. Esas solicitudes sólo se vieron afectadas mientras la cuestión estaba en curso, y las búsquedas posteriores se completaron normalmente. -... ## Root cause Un aumento repentino de la ingestión de documentos concurrentes provocó un elevado número de pasos de validación de documentos simultáneos, que crearon un obstáculo de capacidad en el recurso de infraestructura subyacente más allá de su capacidad de escalado. Una vez que ese recurso estaba saturado, las operaciones de ingestión comenzaron a superar sus límites de tiempo y fracasar. Los registros automáticos de las operaciones fallidas sumaron más carga, lo que mantuvo la condición. Las solicitudes de búsqueda recibidas por el mismo recurso se retrasaron tras el mismo argumento. -... ## Detection Las alertas automatizadas fueron marcadas a medida que se desarrollaba la condición, y una alerta automatizada de capacidad de recursos de infraestructura activada a las 10:37 am UTC la llamó la atención del equipo. -... ## Response **10:03 am UTC** — Las alertas de baja gravedad automatizadas comenzaron a aparecer. - **10:37 am UTC** — Alerta automatizada para la emisión de la capacidad de recursos en la página del equipo. **12:23 pm UTC** Como medida de mitigación se incrementó la capacidad del recurso impactado. **12:57 pm UTC** — Las operaciones de ingestión y búsqueda dejaron de fallar y los tiempos de respuesta volvieron a la normalidad. -... ## Follow-up - **La fijación está desplegada.** La medida de validación ha sido aplicada para hacer cumplir los mismos límites a una pequeña fracción del costo anterior, por lo que este nivel de ingestión concurrente ahora se encuentra dentro de la capacidad disponible. Fue liberado a la región afectada de Estados Unidos el 7 de agosto, antes de lo previsto, y llega a todas las regiones restantes a principios de septiembre. - **Estamos mejorando lo rápido que detectamos problemas como este.** Estamos agregando monitoreo que rastrea si la ingestión de documentos está completando con éxito para los clientes, por lo que los problemas se identifican y actúan directamente en lugar de inferir de las alertas del sistema subyacente. Esto estará en su lugar en todas las regiones para finales de agosto.

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