Historial de interrupciones de Flexera

1. 22 de octubre de 2026 a las 7:05 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta la funcionalidad de Snow Atlas SAM Core en la región del Sur del Reino Unido. Algunos clientes pueden experimentar problemas accediendo a la funcionalidad de los usuarios y pueden encontrar errores al acceder a los Datos de Computación. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente la cuestión y evaluando el alcance del impacto. Estamos trabajando para identificar la causa subyacente y restaurar la funcionalidad afectada. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 22 de octubre de 2026 a las 7:21 UTCmonitoring

   Nuestros equipos técnicos identificaron errores de timeout que afectaron a los componentes de servicio que apoyan la funcionalidad impactada y realizaron reinicias de servicio focalizados. Tras estas acciones de recuperación, la funcionalidad de Usuarios y Detalles de Computación responde con éxito durante la validación. Continuamos monitoreando el comportamiento del servicio y realizando la validación final para confirmar la estabilidad sostenida.

3. 22 de octubre de 2026 a las 7:38 UTCresolved

   Tras las medidas de recuperación aplicadas anteriormente, nuestros equipos técnicos completaron la validación y vigilancia adicionales. La funcionalidad de los usuarios y los detalles de la computadora ha permanecido estable sin más problemas observados. La operación normal ha sido confirmada, y este incidente se considera resuelto.

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

1. 15 de octubre de 2026 a las 22:37 UTCresolved

   Descripción del incidente: Tras la versión programada de Flexera One IT Asset Management 2026R1.4 de producción en la región de Australia, experimentamos un problema que afecta a los servicios de Flexera One IT Asset Management en APAC. Como resultado, los clientes no pudieron acceder a Flexera One IT Asset Management durante el período de impacto. Prioridad: P1 Inicio del impacto: 15 de octubre de 2026 a las 11:34 AM PDT Impact End: 15 de octubre de 2026 a las 12:32 PM PDT Actividad de Restauración: Nuestros equipos técnicos identificaron una cuestión que afecta a los componentes de servicio después de la liberación de producción programada. La rehabilitación se aplicó a los componentes afectados para restaurar la disponibilidad de servicios. Tras la recuperación, los servicios de Flexera One IT Asset Management en APAC regresaron a una operación normal, y la cuestión ahora se considera resuelta.

2. 21 de octubre de 2026 a las 23:40 UTCpostmortem

   **Descripción:** Flexera One - IT Asset Management - APAC - Service Invailability Following 2026R1.4 Liberación **Tiempo:** 15 de octubre de 2026, 11:34 AM PDT - 15 de octubre de 2026, 12:32 PM PDT ## Incident Summary El 15 de octubre de 2026, los clientes que utilizaron Flexera One IT Asset Management en la región de APAC experimentaron una interrupción del servicio que impidió el acceso a la aplicación. La interrupción ocurrió después de la finalización de la versión de producción ITAM 2026R1.4. Aunque inicialmente se disponía de servicios y funcionaba normalmente después de la puesta en libertad, la solicitud se convirtió posteriormente en inaccesible. Los equipos técnicos investigaron la perturbación e identificaron fallos que afectaron la inicialización de los casos de aplicación. Further investigation revealed that the production environment kept a dependncy on a previous application initialization process while a transition to an updated process was underway. Aunque los casos de aplicación se habían inicializado con éxito durante la liberación, los casos de sustitución no pudieron completar el mismo proceso debido a una configuración obsoleta. Los casos de sustitución afectados no pudieron completar la inicialización con éxito o pasar los controles de salud necesarios, evitando que la aplicación regresara a una operación normal. Los equipos técnicos corrigieron la configuración de producción para hacer referencia al proceso de inicialización actualizado y realizaron un refresco de instancia. Tras estos cambios, las instancias afectadas se inicializaron con éxito, y la disponibilidad de servicios de ITAM se restauró aproximadamente a las 12:32 PM PDT. ## Root Cause The incident was caused by a remaining production dependncy on a previous application initialization process during the transition to an updated process in the APAC production environment. Si bien los entornos de ensayo de puesta en escena y aceptación de los usuarios ya habían pasado al proceso actualizado, el entorno de producción de APAC mantenía una configuración que hacía referencia al proceso de inicialización anterior. Durante el lanzamiento de la producción de 2026R1.4, los casos de aplicación se inicializaron manualmente utilizando el proceso actualizado, permitiendo que el ITAM funcionara inicialmente normalmente a pesar de la dependencia de producción restante. Posteriormente se ampliaron los componentes que apoyaban el proceso anterior en el entendimiento de que la transición más amplia había concluido en gran medida. Cuando se iniciaron los casos de aplicación de sustitución, la configuración de producción siguió dirigiendolos al proceso de inicialización anterior. Por lo tanto, los casos afectados no pudieron completar la inicialización con éxito o aprobar sus controles de salud necesarios, lo que dio lugar a la interrupción del servicio. La dependencia de producción restante del proceso de inicialización anterior se confirmó como la causa subyacente del incidente. La corrección de la configuración de producción para utilizar el proceso de inicialización actualizado removió esa dependencia y permitió que los casos de sustitución inicializaran con éxito. ## Remediation Actions Durante la respuesta al incidente se adoptaron las siguientes medidas: 1. **Iniciación de la investigación accidental:** Los equipos técnicos investigaron la falta de disponibilidad de la aplicación y detectaron fallos que afectaron la inicialización y los controles de salud de los casos de aplicación en el entorno de producción de la APAC. 2. ** Número de configuración identificado:** La investigación determinó que la configuración de producción continuaba haciendo referencia al proceso de inicialización de la aplicación anterior en lugar del proceso actualizado. 3. **Configuración de producción Corregido:** La configuración de producción se actualizó para hacer referencia al proceso correcto de inicialización de aplicaciones, eliminando la dependencia del proceso anterior. 4. ** Casos de aplicación reducidos:** Los equipos técnicos realizaron una actualización de instancia después de la corrección de configuración, permitiendo que las instancias de reemplazo inicialicen con éxito. 5. ** Recuperación de servicios validada:** Los equipos técnicos confirmaron que las instancias afectadas estaban inicializando con éxito, los controles de salud de las aplicaciones estaban pasando, y los servicios de ITAM habían regresado a una operación normal. ## Future Preventative Measures Following the incident, a retrospective was conducted to review the application initialization process, remaining production dependencies, release-validation procedures, and opportunities to improve incident detection and response. Se han completado o están en marcha las siguientes medidas correctivas y actividades de mejora: 1. ** Corrección de configuración de producción:** El entorno de producción de APAC se ha actualizado para utilizar el proceso de inicialización de aplicaciones correcto, reemplazando la configuración anterior. 2. ** Validación de la dependencia de derecho:** Se ha establecido una medida de seguimiento para añadir un paso de validación antes de que los componentes de la plataforma heredada se reduzcan o desmantelen, asegurando que los servicios de producción hayan sido plenamente transferidos y no existan dependencias restantes en la plataforma anterior. 3. **Release and Application Health-Check Review:** Se están revisando los controles de salud de las aplicaciones existentes, los procedimientos de validación de la libertad y la cobertura posterior a la prueba de la cordura contra el fracaso observado durante este incidente. En el examen se determinará si existen lagunas de cobertura y si se requieren mejoras adicionales de vigilancia, validación u otras mejoras. 4. ** Investigación sobre la localización de las personas** Seguiremos investigando lo que provocó que las instancias de aplicación originales se escalaran después de la liberación y determinaremos si se requiere alguna acción correctiva o preventiva adicional. 5. ** Mejoras en la comunicación de clientes:** Identificamos una oportunidad para una comunicación más oportuna del cliente durante este incidente. Nuestras prácticas de escalada y comunicación de incidentes establecidas están diseñadas para garantizar la notificación proactiva de los clientes cuando se detecta un impacto de servicio no planificado. El aprendizaje de este incidente se ha incorporado en nuestras prácticas de respuesta a incidentes en curso para ayudar a asegurar que estos procedimientos se apliquen de forma sistemática y que se proporcionen actualizaciones oportunas y proactivas a los clientes durante las interrupciones de los servicios.

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

1. 8 de octubre de 2026 a las 10:59 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta al servicio de licencia dentro de SAM Core. Los usuarios pueden ser incapaces de cargar información de licencia y pueden encontrar mensajes de error al acceder a la funcionalidad del servicio de licencias. La cuestión ha sido confirmada en el Reino Unido Sur y Europa Occidental, y los equipos técnicos están evaluando actualmente el alcance total del impacto. Prioridad: P2 Actividad de Restauración: Los equipos técnicos están investigando activamente la cuestión y revisando el servicio afectado. Se está realizando una validación adicional para determinar el alcance completo del impacto y restaurar el funcionamiento normal del servicio. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 8 de octubre de 2026 a las 11:30 UTCmonitoring

   Hemos identificado la cuestión como relacionada con un despliegue reciente que afecta al servicio de licencias. Se han implementado cambios correctivos y se ha restaurado la funcionalidad de servicio. Actualmente estamos validando la salud de los servicios y vigilando el medio ambiente para garantizar una estabilidad continua. Se proporcionarán nuevas actualizaciones cuando se complete la validación adicional.

3. 8 de octubre de 2026 a las 12:11 UTCresolved

   Tras la validación y un período de monitoreo, el servicio ha permanecido estable y la funcionalidad de Licencia está cargando con éxito en las regiones afectadas. La cuestión ahora se considera resuelta.

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

1. 8 de octubre de 2026 a las 0:08 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta a la funcionalidad de Acuerdos en Snow Atlas para clientes en Australia. Los clientes pueden experimentar datos faltantes o no disponibles al acceder a la pestaña Acuerdos, y las operaciones de actualización de datos pueden fallar. Prioridad: P2 Actividad de restauración: Los equipos técnicos están investigando activamente la cuestión y evaluando el alcance del impacto del cliente. Se está trabajando para identificar la causa del problema y restaurar la funcionalidad normal. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 8 de octubre de 2026 a las 1:39 UTCresolved

   Further investigation identified a communication issue affecting a backend service supporting Agreements function in Snow Atlas Australia. Los equipos técnicos aplicaron medidas de recuperación, entre ellas el reinicio de los componentes de servicios afectados, que restablecieron la comunicación y el funcionamiento normal. La funcionalidad se ha validado en múltiples entornos de clientes, y los datos de Acuerdos ahora se muestran correctamente. No hemos observado ninguna otra cuestión después de las actividades de recuperación y validación. La cuestión ahora se considera resuelta.

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

1. 7 de octubre de 2026 a las 20:27 UTCinvestigating

   Descripción del incidente: Estamos investigando informes de problemas intermitentes que afectan a los clientes de Ocean Kubernetes. Algunos clientes han informado de recibir alertas relacionadas con la conectividad entre los componentes de Ocean Kubernetes y sus grupos. Los equipos técnicos están investigando activamente el alcance de los efectos y la degradación de los servicios conexos. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente el comportamiento reportado, revisando los informes de los clientes y validando el alcance y el impacto en entornos afectados. Proporcionaremos actualizaciones adicionales a medida que se disponga de más información.

2. 7 de octubre de 2026 a las 22:23 UTCinvestigating

   Seguimos investigando los problemas de conectividad intermitente que se habían reportado anteriormente. En este momento no se han observado ocurrencias adicionales desde la ventana de impacto original. Los equipos técnicos están revisando activamente las conclusiones disponibles de telemetría e investigación para determinar la causa subyacente y validar el alcance general del impacto. Se proporcionarán más actualizaciones a medida que se disponga de más información.

3. 8 de octubre de 2026 a las 0:03 UTCinvestigating

   No hemos observado ningún incidente adicional desde la ventana de impacto originalmente reportada, y se ha mantenido la estabilidad de servicio. Los equipos técnicos siguen investigando la causa subyacente de las cuestiones de conectividad intermitente comunicadas hoy.

4. 8 de octubre de 2026 a las 0:04 UTCmonitoring

   Sobre la base de la estabilidad sostenida observada desde la ventana de impacto notificada originalmente y la ausencia de nuevos incidentes notificados, estamos trasladando este incidente a Monitoring. Los equipos técnicos siguen investigando la causa subyacente mientras se vigila la estabilidad de los servicios. Se proporcionarán más actualizaciones a medida que se disponga de más información.

5. 8 de octubre de 2026 a las 2:24 UTCresolved

   No hemos observado ningún incidente adicional desde el impacto original reportado, y se ha mantenido la estabilidad de servicio. Los equipos técnicos completaron la investigación adicional sobre las cuestiones de conectividad intermitente notificadas anteriormente. Durante la investigación se revisaron múltiples correlaciones potenciales, y el análisis final sigue pendiente. Sobre la base de la estabilidad sostenida observada y la ausencia de recurrencia, este incidente se considera resuelto. Los equipos técnicos continuarán realizando actividades de vigilancia e investigación para comprender mejor el comportamiento observado durante la ventana de impacto reportada, y se proporcionará un informe oficial de la RCA una vez que se haya completado el análisis.

6. 20 de octubre de 2026 a las 17:50 UTCpostmortem

   **Descripción:** Spot Ocean - Kubernetes - Cuestiones de conectividad de control intermitente **Tiempo:** Octubre 7, 2026, 11:20 AM PDT - 12:30 PM PDT ** Resumen del incidente** El miércoles 7 de octubre de 2026, a las 11:20 AM PDT, múltiples Spot Ocean for Kubernetes entornos experimentaron alertas intermitentes de conectividad de controlador. Durante el incidente, la plataforma interpretó temporalmente la información de los latidos cardíacos del controlador como operaciones de escalado anticuadas y suspendidas para grupos afectados como medida de seguridad. Los controladores afectados continuaron informando de latidos cardíacos durante el incidente. Sin embargo, el timetamp utilizado para validar la conectividad del controlador se obsoletó dentro de un componente de base de datos, causando que los controladores activos aparezcan temporalmente sin respuesta. El comportamiento era intermitente, y la información actual de latidos cardíacos posteriormente se puso a disposición sin intervención manual, permitiendo que las operaciones de escalado normales se reanudaran. Los equipos técnicos revisaron la vía de procesamiento de latidos cardíacos del controlador, el comportamiento de la base de datos, la telemetría de servicio y las señales de infraestructura relacionadas para determinar por qué la actividad de latidos cardíacos válidos estaba siendo interpretada como un estancamiento. No se observaron incidentes adicionales después de la ventana del incidente. Following continued monitoring and validation of service stability, the incident was considered resolved. *Causa real* El incidente fue causado por un controlador más antiguo ritmo cardíaco sobreescribir un cronograma más reciente válido dentro de un componente de base de datos. Aunque los controladores afectados continuaron reportando latidos cardíacos normalmente, el timetamp anticuado hizo que los latidos cardíacos almacenados más recientemente aparecieran más viejos de lo que era. Cuando la plataforma evaluó este temporizador, superó el umbral de latido cardíaco configurado y desencadenó un mecanismo de seguridad que suspendió temporalmente las operaciones de escalado para los grupos afectados. La condición específica que retrasa la actualización de la base de datos anterior no se ha establecido concluyentemente. Sin embargo, el proceso de actualización de la base de datos no contenía una salvaguardia para evitar que un ritmo cardíaco más antiguo sustituyera un nuevo timetamp válido. Esto permitió retrasar la información de latidos cardíacos para crear la apariencia de que los controladores que informaban activamente no eran responsables. ** Acciones de rehabilitación** Durante la respuesta al incidente se adoptaron las siguientes medidas: 1. Informes de clientes y comportamiento de servicio revisados: equipos técnicos revisaron ejemplos para confirmar el comportamiento, establecer la ventana de impacto, y determinar si el problema estaba aislado o afectar a múltiples entornos. 2. Controller Heartbeat Activity Validated: Controller activity was reviewed to determine whether the affected controladors had stopped reporting. The investigation confirmed that heartbeat information continued to be sent during the incident. 3. Sendero de procesamiento de latidos cardíacos Investigado: Los equipos técnicos rastrearon cómo se generaba, almacenaba y evaluó la información de latidos cardíacos para identificar dónde se interpretaba la actividad actual de latidos cardíacos como obsoletos. 4. Evaluación de la salud de bases de datos y servicios: Relevant database performance, service behaviour, and infrastructure telemetry were reviewed to evaluate potential processing delays and rule out broader platform inestabilidad. 5. La regresión de los tiempos identificados: La investigación determinó que un ritmo cardíaco mayor había sobrescrito un nuevo temporizador válido, causando que la plataforma interpretara temporalmente el latido del corazón como un estancamiento. 6. Validación de la estabilidad de los servicios: Los equipos técnicos siguieron vigilando después de la recuperación. No se observaron incidentes adicionales, y las operaciones de escalado se mantuvieron estables antes de que se cerrara el incidente. **Medidas preventivas completas** Se prevén las siguientes mejoras para fortalecer el procesamiento de latidos cardíacos y mejorar la detección de condiciones similares: 1. Heartbeat Timestamp Protection: El proceso de actualización de la base de datos se modificará para evitar que un ritmo cardíaco más antiguo sobrescriba un timetamp válido más reciente. 2. Mejorado Diagnóstico Logging: Se introducirán registros adicionales en torno a las actualizaciones de latidos cardíacos para capturar la fuente de cada actualización, contexto de solicitud relevante, valores de tiempos anteriores y nuevos, y la fuente del timetamp. 3. Vigilancia y alerta: Se desarrollará un nuevo monitoreo y alerta utilizando la información diagnóstica adicional para identificar las regresiones de los tiempos y condiciones similares de procesamiento de latidos cardíacos más rápidamente. 4. Revisión del acceso a la base de datos: Se revisarán los patrones de acceso a la base de datos asociados al procesamiento de latidos cardíacos para determinar las oportunidades de reducir los retrasos del procesamiento y optimizar el rendimiento bajo carga elevada.

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

1. 29 de septiembre de 2026 a las 11:08 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta al servicio de notificación de eventos en múltiples entornos de producción. Los clientes pueden experimentar retrasos o fallos cuando reciben notificaciones de eventos v2, incluyendo notificaciones enviadas por correo electrónico, webhooks, Slack y otros canales compatibles. Los eventos siguen siendo registrados y siguen siendo accesibles a través de la consola Flexera One y API. Actualmente no hay indicios de que la funcionalidad básica de la plataforma o los datos de eventos hayan sido afectados. Prioridad: P3 Actividad de Restauración: Nuestros equipos técnicos han identificado la cuestión y aplicado acciones de recuperación de servicios. La vigilancia indica que las tasas de error están disminuyendo, y los equipos siguen validando la estabilidad de los servicios y evaluando el alcance completo de los efectos. Se proporcionarán nuevas actualizaciones a medida que avancen las actividades de investigación y recuperación. Update: Further investigation confirmed that this issue did not impact customers. The affected notifications were not intended to be published.

2. 29 de septiembre de 2026 a las 11:53 UTCresolved

   Después de supervisar de cerca los servicios para confirmar la estabilidad, nuestros equipos no observaron más errores o recurrencia de la cuestión. Este incidente ya está resuelto.

3. 13 de octubre de 2026 a las 4:42 UTCpostmortem

   **Descripción:** Lugar por Flexera - Errores de procesamiento de notificaciones de eventos **Tiempo:** 29 de septiembre de 2026, 2:06 AM PDT - 4:51 AM PDT ** Resumen del incidente** El 29 de septiembre de 2026, Flexera identificó errores elevados de aplicación dentro de un componente de procesamiento de notificaciones responsable de manejar ciertos flujos de trabajo de notificación de eventos. La vigilancia automatizada detectó un aumento de la actividad de error, lo que dio lugar a una investigación para determinar si las notificaciones relativas al cliente se vieron afectadas. Durante la investigación, los equipos técnicos detectaron fallos en el proceso de notificación y realizaron una evaluación detallada de los eventos afectados, los flujos de trabajo de notificación y los posibles efectos del cliente. El análisis inicial sugirió que la cuestión podría afectar más ampliamente el procesamiento de las notificaciones, y que se declaró un incidente importante mientras se estaba validando el alcance y los efectos. Further impact assessment confirmed that the affected notifications were not intended to be published to customers. Se siguió registrando con éxito la información sobre los acontecimientos y se mantuvo disponible a través de la plataforma durante toda la investigación. No se interrumpió la funcionalidad del cliente, no se perdieron datos de eventos y no se identificó ningún impacto del cliente como resultado de este problema. Sobre la base de los resultados de la evaluación del impacto, la prioridad del incidente se redujo y la investigación se concluyó después de la validación confirmó que los servicios de atención al cliente no se habían visto afectados. *Causa real* La investigación determinó que un flujo de trabajo de procesamiento de notificaciones tenía una excepción de aplicación mientras manejaba un subconjunto de eventos generados internamente. Estos eventos fueron configurados de tal manera que no estaban destinados a la notificación del cliente. Aunque las excepciones generaban errores elevados de aplicación y justificaban la investigación, el análisis posterior confirmó que no se esperaba que las notificaciones afectadas fueran distribuidas a los clientes. As a result, customer-facing notification delivery, platformfunction, and access to event information were not adversely impacted. ** Acciones de rehabilitación** Durante la respuesta al incidente se adoptaron las siguientes medidas: 1. Investigación de incidentes Iniciada: Los equipos técnicos investigaron errores de aplicación elevados detectados mediante monitoreo automatizado y evaluaron el impacto potencial del cliente. 2. Análisis de procesamiento de notificaciones realizado: Se examinó el flujo de trabajo de notificación afectada para determinar la fuente de las excepciones de aplicación y determinar el alcance de la cuestión. 3. Evaluación del impacto del cliente Complete: Los equipos técnicos validaron los tipos de notificación afectados, revisaron el comportamiento de publicación de eventos, y confirmaron que las notificaciones involucradas no estaban destinadas a la entrega del cliente. 4. Validación y vigilancia del sistema: Se supervisaron las tendencias de error, el comportamiento de los servicios y el procesamiento de notificaciones para confirmar el funcionamiento estable y validar que los servicios de atención al cliente no se vieron afectados. 5. Reclasificación de incidentes completado: Después de confirmar que no existía ningún impacto en el cliente, se redujo la prioridad del incidente y se resolvió formalmente el incidente. **Medidas preventivas completas** Following this investigation, we identified opportunities to improve the speed and accuracy of impact assessment when operational alerts involve internal processing workflows. 1. Mejora de la evaluación de los efectos: Revisar las clasificaciones de las notificaciones internas y los procedimientos de investigación para acelerar la determinación de si una cuestión afecta a la funcionalidad del cliente durante futuros incidentes. 2. Mejoramiento de la notificación Visibilidad del flujo de trabajo: Mejorar la visibilidad operacional en las rutas de procesamiento de notificaciones orientadas al cliente y no al cliente para apoyar actividades más rápidas de validación del impacto y respuesta a incidentes.

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

1. 28 de septiembre de 2026 a las 9:10 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta a la visibilidad de TI en la región de APAC donde los paneles de Power BI no están cargando . Los clientes de la región afectada pueden no poder acceder a los paneles de información dentro de la aplicación. La investigación actual indica que la cuestión se limita a la región del APAC, sin ningún impacto observado en otras regiones en este momento. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente la cuestión para identificar la causa subyacente y restaurar la funcionalidad del informe. Seguimos evaluando el alcance de los efectos, vigilando la salud de los servicios y aplicando medidas correctivas según proceda. Proporcionaremos más actualizaciones a medida que se disponga de más información.

2. 28 de septiembre de 2026 a las 9:26 UTCresolved

   Se ha resuelto la cuestión que afecta a los paneles de información Power BI en la región de la APAC. La investigación inicial indica que se requería una actualización de la configuración tras una actualización reciente. Nuestros equipos técnicos completaron la remediación necesaria, y la validación posterior confirmó que los paneles afectados ahora son accesibles y operan según se espera. Todos los servicios han regresado a una operación normal, y este incidente se considera resuelto.

3. 26 de octubre de 2026 a las 12:10 UTCpostmortem

   **Descripción:** Flexera One- IT Visibility- APAC - Reporting dashboards unvailable **Tiempo:** 28 de septiembre de 2026, 1:38 AM PDT al 28 de septiembre de 2026, 2:15 AM PDT ** Resumen del incidente** El lunes 28 de septiembre de 2026, a las 1:38 AM PDT, Flexera identificó un problema que afectaba el acceso a paneles de información Power BI para clientes de la región APAC. Nuestros equipos técnicos se comprometieron rápidamente y la investigación inicial confirmó que el impacto se limitaba a la APAC, mientras que las otras regiones seguían siendo sensibles. Further investigation determined that settings associated with a planned identity and access management migration had affected the connection settings required by the reporting services. Durante la aplicación de estos cambios, los ajustes de conexión de los servicios de presentación de informes fueron reajustados a valores que no contenían las direcciones completas de servicio necesarias para una comunicación exitosa. En consecuencia, los servicios afectados no comenzaron correctamente, lo que dio lugar a la falta de disponibilidad de paneles de información Power BI para clientes de APAC. Para restaurar el servicio, el equipo técnico corrigió manualmente los ajustes de conexión afectados en el entorno APAC. Esta comunicación restaurada entre los servicios de notificación y autenticación, permitiendo que los servicios afectados se recuperen. Tras la restauración, la validación confirmó que los paneles de información Power BI eran accesibles y funcionaban normalmente a aproximadamente 2:15 AM PDT. *Causa real* The incident was caused by incorrect connection settings applied to the APAC environment during a settings change associated with the identity and access management migration. El cambio reajusta las direcciones de conexión de los servicios de información a valores que no contenían las direcciones completas necesarias para una comunicación exitosa con los servicios de autenticación. Como resultado, los servicios de presentación de informes afectados no comenzaron correctamente, por lo que los paneles de información Power BI no estaban disponibles para los clientes de la región APAC. Factores de contribución * Inconsistencia de configuración: Las direcciones de conexión necesarias se habían actualizado previamente directamente en el entorno, pero no se reflejaban en la configuración de despliegue. En consecuencia, el cambio de configuración posterior reintroducía los valores incorrectos. * La brecha de validación del despliegue: El proceso de despliegue no identificó los ajustes de conexión incorrectos antes de que afectaran la disponibilidad de servicios. * Cambio de coordinación y validación de dependencia: El proceso de migración no tenía plenamente en cuenta los requisitos de configuración de todos los servicios dependientes, lo que dio lugar a que se aplicaran cambios de punto final sin una validación previa en todas las dependencias de servicios afectadas. ** Acciones de rehabilitación** Nuestros equipos realizaron las siguientes acciones para restaurar los servicios a la normalidad: * Los ajustes de conexión afectados fueron corregidos para restaurar la comunicación entre los servicios de notificación y autenticación. * Los servicios afectados recuperados y la validación confirmaron que los paneles de información Power BI eran accesibles y operan normalmente. * Posteriormente se corrigió la configuración para garantizar que los ajustes necesarios de conexión se mantengan de forma sistemática para futuros despliegues. **Medidas preventivas completas** Se han identificado las siguientes medidas y se están trabajando para reducir la probabilidad de recurrencia y mejorar la resiliencia de los servicios: * Gestión de configuración: Asegurar que los cambios de configuración de servicio se gestionan de forma sistemática para evitar discrepancias entre los ajustes desplegados y las configuraciones mantenidas. * Validación del despliegue: Revisar los cambios de configuración previstos antes del despliegue para verificar que los ajustes necesarios de conexión de servicio sigan siendo correctos. *Congruencia de configuración: Asegurar que los ajustes de conexión críticos se mantengan en las fuentes de configuración apropiadas y no dependen de cambios manuales en entornos individuales. * Coordinación del cambio: Mejorar la coordinación de las migraciones planificadas y los cambios de configuración, incluida la validación de los requisitos y dependencias de los servicios afectados. * Salvaguardias del despliegue: Fortalecer las comprobaciones previas al despliegue para identificar configuraciones incorrectas antes de que causen fallos de servicio.

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

1. 25 de septiembre de 2026 a las 23:18 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta a ciertos servicios de integración de la gestión de activos de TI y Portal de aplicaciones en todas las regiones. Los clientes que utilizan integraciones basadas en API afectadas pueden experimentar fallos de autenticación que resultan en HTTP 401 Errores no autorizados, lo que puede impedir que las solicitudes se completen con éxito. Los usuarios de App Portal también pueden encontrar errores al presentar solicitudes. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente la cuestión y evaluando las acciones correctivas. Se están llevando a cabo actividades de investigación y validación, y estamos trabajando para restaurar la funcionalidad de servicio normal lo antes posible. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 26 de septiembre de 2026 a las 5:31 UTCidentified

   El hotfix corregido está actualmente pendiente de completar el proceso de construcción, que está tomando más tiempo de lo esperado. Una vez que la construcción esté completa, nuestros equipos técnicos procederán con validación UAT antes de avanzar con el despliegue de producción. El equipo también está trabajando para confirmar el plan de despliegue, la propiedad y el calendario previsto. Se proporcionarán más actualizaciones a medida que avancen estas actividades.

3. 26 de septiembre de 2026 a las 12:30 UTCmonitoring

   Nuestros equipos han implementado con éxito un hotfix, y la validación inicial confirma que los servicios funcionan como se espera. Seguimos vigilando de cerca el medio ambiente mientras esperamos la confirmación de los clientes afectados.

4. 27 de septiembre de 2026 a las 5:39 UTCmonitoring

   Las API funcionan como se espera, y los errores previamente observados ya no se están detectando. El incidente permanece en vigilancia mientras se completa la validación adicional y se obtiene la confirmación del cliente.

5. 28 de septiembre de 2026 a las 17:14 UTCresolved

   Tras las actividades de rehabilitación realizadas durante el fin de semana, continuamos vigilando los servicios afectados para validar la estabilidad y la recuperación sostenidas. Se ha recibido la validación del cliente confirmando que la funcionalidad de App Portal y el procesamiento de solicitudes API funcionan normalmente. Further investigation identified an issue affecting autation processing within a service component, resulting in HTTP 401 Unauthorized errors for affected API requests and errors when submitting requests through App Portal. Nuestros equipos técnicos aplicaron medidas correctivas para abordar la cuestión y realizaron una validación adicional después de identificar y resolver un problema separado que se encontró durante el proceso de rehabilitación. Following remediation and extended monitoring, services have remained stable with no further issues observed. Se llevará a cabo un análisis completo de las causas profundas y se compartirá un informe posterior al incidente detallando la causa raíz, las actividades de rehabilitación y las medidas correctivas identificadas como parte de la investigación.

6. 8 de octubre de 2026 a las 11:25 UTCpostmortem

   **Descripción:** Flexera One – Gestión de Activos de TI – Todas las Regiones – Errores de Portal de Aplicación y fracasos de solicitud de API **Tiempo:** 24 de septiembre de 2026, 12:12 PM PDT – 26 de septiembre de 2026, 4:38 AM PDT ** Resumen del incidente** A partir del 24 de septiembre de 2026, aproximadamente a las 12:12 PM PDT, los clientes que utilizan integraciones basadas en API con Flexera One IT Asset Management \(ITAM\) experimentaron fallos de autenticación que devolvieron HTTP 401 Respuestas no autorizadas. Los usuarios de App Portal también encontraron errores cuando presentaron solicitudes, e integraciones como App Broker y Business Adapter que dependen de estas API fueron afectadas. Se observaron efectos en las regiones de América del Norte, Europa y Asia y el Pacífico. Los equipos técnicos investigaron y confirmaron que los fallos no estaban relacionados con las credenciales del cliente o la configuración del cliente. Los registros de aplicaciones demostraron que los componentes necesarios para autenticar estas solicitudes no estaban inicializando. Otras investigaciones determinaron que el comportamiento fue introducido por un hotfix desplegado como medida preventiva durante la respuesta al incidente anterior de carga del menú ITAM el 24 de septiembre. Los equipos técnicos reprodujeron el comportamiento en pruebas, desarrollaron una corrección y la validaron. Durante la validación del despliegue, se identificó y abordó una cuestión secundaria de carga de componentes mediante un hotfix actualizado. Tras el despliegue del hotfix actualizado a Producción, los equipos técnicos comprobaron que la funcionalidad de API funcionaba según lo previsto, y el servicio fue restaurado el 26 de septiembre aproximadamente a las 4:38 AM PDT. El incidente se trasladó a una vigilancia ampliada mientras se obtuvo la confirmación del cliente, y se recibió confirmación el 28 de septiembre. Following the restoration of service, isolated intermittent autation failures were reported and investigated separately from the main incident. Los equipos técnicos determinaron nuevas condiciones de conexión y configuración específicas para el medio ambiente y desplegaron nuevos hotfixes, que se validaron hasta el 30 de septiembre. La vigilancia continuada y la revisión del cliente hasta el 1 de octubre confirmaron que la cuestión ya no podía reproducirse y que no se habían observado otros acontecimientos. *Causa real* El incidente fue causado por un defecto en un hotfix que se desplegó como medida preventiva durante la respuesta al incidente anterior de carga del menú ITAM el 24 de septiembre. El hotfix removió una dependencia de los componentes de autenticación de la aplicación y cambió cómo la aplicación lee la configuración que utiliza para conectarse a los servicios de autenticación. Los ajustes necesarios estaban presentes en la configuración desplegada. Sin embargo, la aplicación intentó leerlos usando un método que no es compatible con la configuración cargada en tiempo de ejecución. Como resultado, los componentes necesarios para la autenticación no podían ser inicializados, y las solicitudes que requerían autenticación fueron rechazadas como no autorizadas. Esto produjo errores de API y fallos de solicitud de App Portal que los clientes experimentaron. El mismo comportamiento ocurrió en el entorno de validación de preproducción cuando el hotfix fue aplicado allí. No se identificó antes de que el hotfix llegara a Producción porque las API afectadas no se utilizan activamente en ese entorno, y el aviso específico de error todavía no estaba en su lugar. La solución inicial abordaba el defecto de configuración principal. Durante la posterior validación y vigilancia, se determinaron nuevas condiciones de configuración de carga de componentes, conexión y configuración específicas para el medio ambiente y se requirieron nuevos focos antes de que se pudiera confirmar la estabilidad sostenida. ** Acciones de rehabilitación** Durante la respuesta al incidente se adoptaron las siguientes medidas: 1. Respuesta del incidente Iniciada: Los equipos técnicos comenzaron a investigar después de que los clientes reportaron fallas de autenticación y errores de API. 2. Alcance y configuración del cliente Evaluado: Los equipos técnicos confirmaron que los fallos no estaban relacionados con las credenciales o configuración del cliente, y confirmaron que el impacto se extendió a múltiples regiones. 3. Estado subyacente Identificado: Los equipos técnicos determinaron que los ajustes necesarios de autenticación estaban presentes pero no podían leerse en tiempo de ejecución, y reprodujeron el comportamiento en pruebas. 4. Corrective Fix Desarrollado y validado: El código de aplicación fue actualizado para leer la configuración utilizando un método compatible. Las pruebas de validación confirmaron que los errores de autenticación ya no se produjeron. Se desplegó un plan correccional y se restauró el servicio: se abordó una cuestión secundaria de carga de componentes identificada durante la validación del despliegue mediante un sistema de información caliente actualizado. Después de que el hotfix actualizado se desplegó en Producción, los equipos técnicos verificaron que la funcionalidad de API estaba funcionando como se esperaba. 6. Vigilancia ampliada y validación del cliente: Los equipos técnicos supervisaron el comportamiento del servicio durante el fin de semana y obtuvieron confirmación de un cliente afectado. 7. Remediación posterior al incidente: Después de que se notificaron fallos intermitentes aislados tras la restauración del servicio, los equipos técnicos desplegaron nuevos focos y los validaron hasta el 30 de septiembre. La vigilancia y la revisión del cliente continuaron hasta el 1 de octubre para confirmar que la cuestión ya no ocurrió. **Medidas preventivas completas** Tras el incidente, realizamos una retrospectiva para revisar la causa técnica, el proceso de validación de hotfix, las capacidades de monitoreo y los factores que contribuyeron al impacto del cliente. Se han completado o se están aplicando las siguientes medidas: 1. Corrección de configuración de tiempo de ejecución: Se ha corregido la aplicación para leer su configuración de autenticación utilizando un método compatible, y se han desplegado y validado nuevos hotfixes en entornos de producción. 2. API Monitoring and Alerting: Se está añadiendo alerta de tasa de error a las API afectadas para que se detecten fallos de autenticación tanto en entornos preproducción como de producción, incluso cuando el servicio no se utiliza activamente. 3. Proceso de validación de Hotfix: Estamos evaluando cheques adicionales de servicios dependientes, como integraciones de API y funcionalidad de App Portal, como parte de validación de hotfix antes de que los cambios sean aprobados para Producción.

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

1. 25 de septiembre de 2026 a las 16:19 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta a un subconjunto de clientes de Flexera One IT Asset Management. Los clientes afectados pueden experimentar datos de inventario perdidos o resultados vacíos al acceder a la vista de All Inventory y las opiniones conexas basadas en inventarios. El tema se limita a un subconjunto de clientes en América del Norte. Prioridad: P2 Actividad de restauración: Los equipos técnicos están investigando activamente la cuestión y revisando los flujos de trabajo de procesamiento de datos de inventario asociados con la funcionalidad afectada. Se está validando el alcance de los efectos mientras se evalúan las opciones de mitigación y recuperación. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 25 de septiembre de 2026 a las 18:50 UTCidentified

   Los equipos técnicos han determinado una posible causa de la cuestión relacionada con un cambio reciente de nivel de capacidad que afecta al procesamiento de datos de inventario. Se están llevando a cabo actividades de recuperación, incluidas medidas de retroceso y corrección destinadas a restaurar el procesamiento normal de datos de inventario. Los equipos técnicos están trabajando activamente a través de la rehabilitación y validación de la recuperación para los clientes afectados. Se proporcionarán más actualizaciones a medida que se disponga de más información.

3. 25 de septiembre de 2026 a las 21:22 UTCidentified

   Los equipos técnicos siguen trabajando mediante actividades de rehabilitación relacionadas con la cuestión y están ejecutando activamente medidas de recuperación destinadas a restaurar el procesamiento normal de datos de inventario. Durante la ejecución, los equipos encontraron condiciones adicionales que requerían ajustes en el enfoque de rehabilitación, y se están realizando actividades de recuperación actualizadas. Los equipos técnicos siguen participando activamente y trabajan continuamente para completar la remediación y restaurar el servicio normal para los clientes afectados lo antes posible. Apreciamos su paciencia mientras estos esfuerzos continúan y se disculpan por el impacto continuo. Se proporcionarán nuevas actualizaciones a medida que se avance significativamente.

4. 26 de septiembre de 2026 a las 0:55 UTCidentified

   Los equipos técnicos continúan trabajando a través de actividades de remediación relacionadas con la cuestión y están ejecutando activamente medidas de retroceso y corrección diseñadas para restaurar el procesamiento normal de datos de inventario. Las actividades de recuperación siguen en curso, y los equipos técnicos están vigilando activamente la ejecución como resultado de la rehabilitación.

5. 26 de septiembre de 2026 a las 5:25 UTCmonitoring

   Nuestros equipos técnicos completaron con éxito la actividad necesaria de rehabilitación. Las tareas de bloqueo fueron limpiadas. La validación posterior a la rehabilitación confirmó que las funciones y procedimientos pertinentes de la base de datos funcionan en el estado previsto. Los equipos seguirán vigilando el medio ambiente para garantizar la estabilidad.

6. 26 de septiembre de 2026 a las 7:13 UTCresolved

   Todos los controles de validación se han completado con éxito, y los servicios han regresado a la operación normal. La cuestión se resuelve ahora.

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

1. 24 de septiembre de 2026 a las 21:43 UTCidentified

   Descripción del incidente: Estamos investigando un problema que afecta a Spot Ocean para AWS. Los clientes pueden ser incapaces de lanzar nuevas instancias debido a fallos de provisión de instancia. En consecuencia, los grupos afectados pueden no ser capaces de escalar según lo previsto. Las cargas de trabajo existentes siguen funcionando. Nuestros equipos técnicos están investigando activamente el alcance y el impacto de la cuestión. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos han identificado una posible cuestión relacionada con un cambio reciente que afecta a la provisión de instancias y están validando activamente el impacto. Se están llevando a cabo actividades de mitigación, incluido el retroceso de un cambio reciente mientras los equipos supervisan la recuperación y el comportamiento de los servicios. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 24 de septiembre de 2026 a las 22:16 UTCresolved

   Further investigation determined that a recent change affecting instance provisioning behaviour contributed to the issue. Los equipos técnicos completaron un retroceso del cambio y validaron la recuperación. Tras el retroceso, los niveles de error regresaron a una instancia normal y nueva que se reanudó con éxito. A lo largo del incidente, los casos y el volumen de trabajo existentes seguían funcionando. El impacto se limitó a nuevos lanzamientos de instancias y operaciones de ampliación de grupos. La cuestión ahora se considera resuelta. Después de concluir el análisis de las causas profundas y el examen posterior a los incidentes, se compartirá un informe detallado después de la mortem, en el que se documentará la secuencia completa de los acontecimientos, los factores que contribuyen, la experiencia adquirida y las medidas de seguimiento que se determinen.

3. 9 de octubre de 2026 a las 6:33 UTCpostmortem

   **Descripción:** Spot Ocean for AWS – Instance Provisioning Failures **Tiempo:** 24 de septiembre de 2026, 12:00 PDT al 24 de septiembre de 2026, 2:54 PM PDT ** Resumen del incidente** El 24 de septiembre de 2026, Spot Ocean for AWS experimentó un problema que impidió que algunos clientes lanzaran nuevas instancias. Como resultado de ello, los grupos afectados no pudieron escalar según lo previsto cuando se requería una capacidad adicional de cálculo. Durante el incidente siguieron funcionando casos y cargas de trabajo existentes. Los efectos se limitaban a las operaciones de suministro de nuevas instancias y ampliación de grupos temáticos. El equipo técnico identificó que un cambio de software reciente introdujo comportamiento inesperado durante el proceso de provisión de instancias. El cambio se revolvió, lo que despejó los errores de provisión y restauró el funcionamiento normal del servicio. Tras el retroceso, se identificó y corrigió la cuestión del software subyacente. La funcionalidad actualizada ha experimentado una validación adicional para asegurar que la cuestión se aborde plenamente antes de que se vuelva a introducir en el entorno de producción. Los equipos técnicos validaron los lanzamientos exitosos de instancia después de la devolución, y la validación del cliente confirmó que la provisión de nuevas instancias funcionaba como se esperaba. El incidente se resolvió a las 2:54 PM PDT el 24 de septiembre de 2026. *Causa real* The incident was caused by a recent software change that introduced unintended behaviour during AWS instance provisioning. El cambio afectó a la forma en que se tramitó cierta información sobre la configuración de grupos, lo que dio lugar a que se proporcionaran fallos para algunas operaciones de ampliación. Si bien el cambio fue diseñado para apoyar la etiquetación de recursos específicos de AWS, su comportamiento también afectó a otras configuraciones de grupos compatibles. En determinadas condiciones, la lógica de etiquetado actualizada dio lugar a que se presentara información de etiquetas duplicadas como parte de la solicitud de presentación de casos. AWS rechazó estas solicitudes porque la información de la etiqueta no cumplía los requisitos previstos. As a result, Spot Ocean was unable to successfully complete the provisioning of some new instances. Esto afectó principalmente los lanzamientos de nuevas instancias y las operaciones de ampliación de agrupaciones. Los casos existentes ya se han facilitado con éxito y, por consiguiente, siguen funcionando normalmente durante todo el incidente. Desde entonces se ha corregido la funcionalidad subyacente, y se está realizando una validación adicional para asegurar que el comportamiento actualizado funcione de forma consistente en las configuraciones de agrupación AWS apoyadas antes de que se devuelva a la producción. ** Acciones de rehabilitación** Nuestros equipos realizaron las siguientes acciones para restaurar los servicios a la normalidad: * Retrocedió el cambio de software, restaurando la provisión de instancia normal. * Identificado y corregido el problema subyacente en la funcionalidad afectada. * Realizar validación adicional de la funcionalidad corregida. * Introdujo salvaguardias adicionales para permitir que la funcionalidad actualizada se ejecute de manera controlada. * Validated that new instance provisioning and cluster scaling operations were functioning as expected following the rollback. **Medidas preventivas completas** * Ampliar las pruebas automatizadas, por ejemplo, los escenarios de provisión y escala de grupos. * Aumentar las pruebas de regresión a través de configuraciones de grupos AWS compatibles. * Ampliar las pruebas de extremo a extremo para escalar los flujos de trabajo. * Mejorar la vigilancia y alerta para el suministro y el aumento de fallos. * Fortalecer la validación de los cambios antes del despliegue de producción. * Introducir salvaguardias adicionales para el despliegue controlado de cambios que afectan el comportamiento de provisión. * Aumentar la cobertura de pruebas para casos de borde y escenarios de manejo de errores.

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

1. 24 de septiembre de 2026 a las 20:46 UTCmonitoring

   Descripción del incidente: A principios de hoy, un problema que afecta al procesamiento del inventario en Flexera One IT Asset Management (ITAM) en la región del NAM impactó un subconjunto de clientes. La investigación determinó que las subidas de inventario se estaban recibiendo con éxito pero no se estaban tramitando para los clientes afectados, lo que dio lugar a demoras en los datos de inventario reflejados en Flexera One ITAM. Las medidas de recuperación se aplicaron y el procesamiento de inventario se ha reanudado con éxito. Los archivos de inventario continúan procesando normalmente; sin embargo, la recuperación del atraso restante sigue en curso y se está rastreando a través de este incidente. Prioridad: P2 Actividad de Restauración: Los equipos técnicos implementaron acciones de recuperación que restauraron el procesamiento de archivos de inventario y han validado el procesamiento exitoso mediante monitoreo y registro. La operación de servicio sigue siendo estable, y la recuperación atrasada continúa a medida que se procesan los archivos de inventarios previamente archivados. Los equipos técnicos están monitoreando activamente el progreso de la recuperación, la salud de los servicios y la reducción atrasada mientras continúan las actividades de validación en curso. Las actualizaciones anteriores relacionadas con las etapas anteriores de este incidente se pueden encontrar en la historia del incidente que se relaciona a continuación. Se proporcionarán nuevas actualizaciones a medida que continúen los progresos de recuperación atrasados y las actividades de validación. https://status.flexera.com/incidents/5wrg6jl9bj2h

2. 25 de septiembre de 2026 a las 8:15 UTCmonitoring

   La recuperación atrasada continúa mientras los archivos de inventario previamente archivados se procesan. Los niveles de atraso se encuentran dentro de un rango aceptable, con una organización que permanece por encima de los niveles esperados. Los equipos técnicos siguen vigilando la recuperación, la salud de los servicios y la actividad de procesamiento, mientras que la validación sigue en curso.

3. 25 de septiembre de 2026 a las 13:28 UTCresolved

   El atraso acumulado durante el incidente ha sido procesado con éxito, y los niveles de procesamiento han regresado a los rangos operativos normales. Nuestros equipos han completado la validación de la recuperación, y este incidente se está resolviendo. En el informe posterior a la mortem se proporcionarán más detalles sobre la causa subyacente y las medidas adoptadas.

4. 23 de octubre de 2026 a las 17:27 UTCpostmortem

   **Descripción:** Flexera One - IT Asset Management - NAM - Inventory Processing Delays Following Production Activity **Tiempo:** 22 de septiembre de 2026, 7:05 PM PDT - 25 de septiembre de 2026, 5:30 AM PDT ** Resumen del incidente** El 24 de septiembre de 2026, equipos técnicos comenzaron a investigar informes de actualizaciones de inventario retrasadas que afectaron a un subconjunto de clientes utilizando Flexera One IT Asset Management \(ITAM\) en la región de Norteamérica \(NAM\). Aunque los archivos de inventario se estaban cargando con éxito y seguían disponibles, algunos clientes experimentaron retrasos en el procesamiento de estos archivos, impidiendo que la última información de inventario se reflejara en la aplicación. La información de estado de Beacon mostrada en ITAM también podría haber sido anticuada para los clientes afectados. El procesamiento de inventario continuó normalmente para otros clientes. La cuestión se produjo después de la actividad de liberación de producción ITAM 2026R1.3 el 22 de septiembre de 2026. La investigación identificó una interrupción en el proceso responsable de transferir archivos de inventario cargados a los servicios de procesamiento de inventarios de ITAM. Si bien los archivos afectados seguían disponibles en almacenamiento, no estaban siendo remitidos para su procesamiento. Los equipos técnicos también observaron errores elevados de aplicación durante la investigación, aunque estos errores no se establecieron concluyentemente como causa de la interrupción. Los equipos técnicos realizaron un reinicio específico del componente de servicio afectado, restaurando la transferencia de archivos de inventario y permitiendo que el procesamiento se reanudara para clientes previamente afectados. Se ha habilitado la tala de diagnóstico adicional para apoyar nuevas investigaciones. Sin embargo, durante la interrupción se había acumulado un atraso considerable de los archivos de inventario y se requería tiempo adicional para procesarlos. Tras la restauración del procesamiento, los equipos técnicos continuaron vigilando la actividad de inventario y el atraso acumulado. Para el viernes 25 de septiembre de 2026, aproximadamente a las 5:30 AM PDT, el atraso relacionado con incidentes había retornado a niveles operativos normales, confirmando la recuperación del procesamiento del inventario. *Causa real* El incidente fue causado por una interrupción del flujo de trabajo de procesamiento de inventarios tras la actividad de lanzamiento de producción ITAM 2026R1.3 en la región del NAM. Aunque los archivos de inventario fueron cargados con éxito y permanecieron disponibles en almacenamiento, el componente responsable de enviar estos archivos al procesamiento de ITAM dejó de transferir datos de inventario para un subconjunto de clientes. Como resultado, los archivos de inventario afectados no se procesaron, retrasando las actualizaciones de inventario. La cuestión no afectaba a todos los clientes, ya que el procesamiento de inventario continuaba normalmente para otras organizaciones. Investigación identificó errores de aplicación elevados y comportamiento indicando que el componente de procesamiento afectado no se estaba recuperando como se esperaba. La condición técnica precisa responsable de la interrupción parcial sigue siendo investigada. Un reinicio específico del componente de servicio afectado restaurado procesamiento de inventario para clientes afectados. Posteriormente se tramitó el atraso acumulado, lo que permitió que las actualizaciones del inventario volvieran a niveles normales. ** Acciones de rehabilitación** Durante la respuesta al incidente se adoptaron las siguientes medidas: 1. **Iniciación de la investigación accidental:** Los equipos técnicos investigaron los informes de actualizaciones de inventario retrasadas que afectaron a un subconjunto de clientes de la región del MNOAL y examinaron el flujo de trabajo de procesamiento de inventarios para determinar el alcance de la cuestión. 2. ** Interrupción de Procesamiento Inventario:** La investigación confirmó que los archivos de inventario cargados estaban disponibles en almacenamiento, pero no estaban siendo enviados a los servicios de procesamiento para los clientes afectados. 3. **Afectado componente de servicio Un reinicio específico del componente de servicio afectado restauró la transferencia de archivos de inventario y permitió que el procesamiento reanudara para clientes previamente afectados. 4. **Tabla de diagnóstico adicional:** Se permitió obtener más información técnica y apoyar la investigación continuada de la interrupción del proceso subyacente. 5. **Inventory Backlog Recovery Monitored:** Los equipos técnicos supervisaron el atraso acumulado del inventario tras la restauración del procesamiento y confirmaron que los archivos de inventario se estaban procesando con éxito. 6. ** Recuperación de servicios validada:** Los equipos técnicos confirmaron que el atraso relacionado con incidentes había regresado a los niveles operativos normales antes del 25 de septiembre y que el procesamiento de inventario seguía siendo estable. **Medidas preventivas completas** Tras el incidente, realizamos una retrospectiva para revisar el fallo de procesamiento parcial de inventarios, la arquitectura existente de entrega de inventarios, la información de diagnóstico disponible y las oportunidades de mejorar la fiabilidad de procesamiento y la visibilidad de fallos. Se están llevando a cabo las siguientes acciones correctivas y actividades de mejora: 1. ** Mejora de la Arquitectura de Procesamiento Inventario:** Se prevé trabajar para simplificar la integración de procesamiento de inventarios permitiendo a ITAM recuperar archivos de inventario cargados directamente desde la capa de almacenamiento en lugar de depender del servicio de reenvío intermedio existente. Este cambio eliminará una dependencia adicional de la vía de procesamiento y proporcionará un mayor control sobre el procesamiento, la gestión atrasada, la capacidad y la recuperación. 2. ** Diagnósticos mejorados de falla:** La tala diagnóstica y la telemetría necesarias para captar el estado de servicio pertinente durante un fallo de procesamiento parcial de inventario se evaluarán y mejorarán según proceda. Esto proporcionará información técnica mejorada para apoyar la determinación de la causa raíz si se repite una condición similar.

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

1. 24 de septiembre de 2026 a las 14:08 UTCinvestigating

   Descripción del incidente: Estamos investigando un problema que afecta a un subconjunto de clientes usando Flexera One IT Asset Management (ITAM) en la región del NAM. Los clientes afectados pueden experimentar problemas con la navegación, incluyendo los elementos de menú que no están siendo visibles en la interfaz ITAM, dando como resultado un acceso limitado a alguna funcionalidad. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente esta cuestión y trabajando para restaurar la plena funcionalidad. Seguiremos proporcionando actualizaciones a medida que se disponga de más información.

2. 24 de septiembre de 2026 a las 15:44 UTCinvestigating

   Los equipos técnicos siguen investigando la cuestión que afecta a la gestión de activos de TI Flexera One en el entorno de producción de NAM. Los esfuerzos actuales se centran en determinar dónde se producen los fracasos dentro del flujo de trabajo afectado. Los equipos están revisando el comportamiento de las aplicaciones, los procesos de validación, las interacciones de los servicios, la telemetría de las plataformas y cualquier cambio reciente o las condiciones ambientales que puedan contribuir al problema. La investigación sigue en curso y se proporcionarán nuevas actualizaciones a medida que se disponga de información adicional.

3. 24 de septiembre de 2026 a las 17:48 UTCinvestigating

   Los equipos técnicos han logrado avances en la reducción del alcance de la cuestión y se están centrando en los componentes de aplicación relacionados con la carga del acceso de los usuarios y la información de navegación. Los resultados actuales indican que algunas solicitudes dentro de este proceso no se completan como se espera, lo que da lugar a que los elementos del menú no se carguen para los usuarios afectados. Se sigue trabajando para determinar la causa subyacente y validar la rehabilitación adecuada. Se proporcionarán actualizaciones adicionales a medida que se disponga de más información.

4. 24 de septiembre de 2026 a las 18:39 UTCmonitoring

   Los equipos técnicos están observando actualmente un comportamiento estable de servicio y una reducción significativa de los errores asociados con este incidente. Las funciones de aplicación afectadas funcionan normalmente sobre la base de datos de telemetría y vigilancia actuales. Si bien la estabilidad de los servicios ha mejorado, los equipos técnicos siguen vigilando estrechamente el medio ambiente para confirmar que la cuestión no se repite. La investigación de la causa subyacente sigue en curso. Seguiremos vigilando y proporcionaremos más actualizaciones a medida que se disponga de información adicional.

5. 24 de septiembre de 2026 a las 20:33 UTCresolved

   Los equipos técnicos han confirmado que el servicio ha permanecido estable y la funcionalidad de gestión de activos de TI afectada está funcionando normalmente. Durante la investigación, los equipos técnicos determinaron las condiciones de saturación de conexiones que afectan a los componentes de aplicaciones responsables de las funciones de acceso y navegación de los usuarios. Estas condiciones se observaron durante la ventana de impacto y coincidieron con los fallos experimentados por los usuarios afectados. La funcionalidad del servicio recuperada, y la validación del cliente confirmó que las páginas de ITAM afectados y los elementos del menú estaban cargando con éxito. Tras un período de vigilancia sin repetición de la cuestión, el incidente se considera resuelto. Se está llevando a cabo un examen detallado del incidente para seguir validando los factores de contribución e identificar cualquier medida preventiva adicional.

6. 8 de octubre de 2026 a las 11:23 UTCpostmortem

   **Descripción:** Flexera One – IT Asset Management – NAM – Menu Temas No Cargando **Hora:** 24 de septiembre de 2026, 5:27 AM PDT – 24 de septiembre de 2026, 10:48 AM PDT ** Resumen del incidente** El 24 de septiembre de 2026, los clientes que utilizan Flexera One IT Asset Management \(ITAM\) en la región de América del Norte experimentaron problemas intermitentes cargando los elementos del menú de aplicación y accediendo porciones de funcionalidad ITAM. Algunos clientes encontraron menús cargados o desaparecidos parcialmente, mensajes de error y comportamiento de aplicación inconsistente. Los equipos técnicos investigaron la cuestión a través de la aplicación y los servicios de apoyo e identificaron la utilización de conexiones anormales dentro de los componentes que apoyan la funcionalidad de ITAM. A medida que se agotó la capacidad de conexión disponible, algunas solicitudes de aplicaciones ya no pudieron completarse con éxito, lo que dio lugar a fallos relacionados con la autenticación y a la prevención de la carga de partes de la funcionalidad de ITAM. El servicio comenzó a recuperarse aproximadamente a las 10:46 AM PDT, antes de que se terminara el despliegue del hotfix correctivo. Los últimos errores de aplicación relacionados se registraron a las 10:48 AM PDT. Los equipos técnicos continuaron investigando la causa subyacente mientras monitoreaban el medio ambiente y validaban la funcionalidad del cliente. El análisis posterior al incidente indicó que los servicios de aplicaciones en los servidores afectados habían reiniciado, liberando conexiones acumuladas y permitiendo establecer nuevas conexiones. The corrective hotfix was subsequently deployed as a preventative measure to address the connection-handling behaviour while investigation into the underlying cause continued. Tras la vigilancia continua y la validación del cliente, los equipos técnicos confirmaron que la funcionalidad de ITAM había retornado a una operación normal. *Causa real* The incident was caused by a connection-management issue introduced during the ITAM 2026 R1.3 production release. Un cambio en el flujo de autenticación de aplicaciones hizo que se crearan nuevas conexiones de servicio repetidamente en lugar de reutilizar las conexiones existentes. Con el tiempo, estas conexiones acumularon y agotaron la capacidad de conexión disponible dentro de los componentes de aplicación afectados. Una vez agotada esa capacidad, no se podían establecer con éxito nuevas solicitudes de solicitud. Esto dio lugar a fallos relacionados con la autenticación e impidió que las partes de la funcionalidad ITAM se cargaran, causando faltas de menú, mensajes de error y pérdida intermitente de acceso para los clientes afectados. Un hotfix que corrigía este comportamiento ya había sido creado y fue incluido en el plan de despliegue de liberación antes del despliegue de producción. El hotfix había sido designado inicialmente para el entorno de validación porque la producción aún no había sido actualizada. Se pretendía aplicar a la producción como parte de la versión R1.3, pero no se aplicaba durante el despliegue de la producción. Como resultado, la corrección de la gestión de conexiones no estaba en vigor cuando la liberación fue en directo. ** Acciones de rehabilitación** 1. Investigación de incidentes Iniciada: Los equipos técnicos investigaron los errores de aplicación y la pérdida intermitente de la funcionalidad de ITAM para determinar el alcance y la causa subyacente. 2. Saturación de conexión Identificada: El análisis de los componentes de aplicación afectados identificó una acumulación de conexión anormal que agotó la capacidad de conexión disponible e impidiendo que las nuevas solicitudes de aplicación completaran con éxito. 3. Hotfix correccional Confirmado: Los equipos técnicos identificaron el hotfix existente que corrigió el comportamiento de conexión reutilizando conexiones de servicio en lugar de crear nuevas conexiones para cada solicitud. 4. Hotfix correccional Deployed: The hotfix was deployed to Production as a preventative measure to address the connection-management issue and prevent further connection acumulación. 5. Service Recovery Validated: Los equipos técnicos continuaron monitoreando el comportamiento de la aplicación y validando la funcionalidad del cliente después de la recuperación para confirmar que los servicios de ITAM habían regresado a la operación normal. **Medidas preventivas completas** Tras el incidente, realizamos una retrospectiva para revisar el proceso de causa técnica, liberación y despliegue de hotfix, capacidades de monitoreo y factores que contribuyeron al impacto del cliente. Se han completado o se están aplicando las siguientes medidas: 1. Corrección de gestión de conexiones: Se ha aplicado el cambio correctivo para asegurar que las conexiones de servicio se reutilizan adecuadamente y para evitar que la acumulación de conexiones agote los recursos de aplicación disponibles. 2. Validación del despliegue de la producción: La corrección de la gestión de las conexiones se ha desplegado y validado en todas las regiones de producción para asegurar una aplicación coherente. 3. Mejoras del proceso de liberación y de Hotfix: se están fortaleciendo los procedimientos de liberación para que los hotfixes incluidos en los planes de despliegue de lanzamiento sean designados sistemáticamente para el despliegue de producción, incluidos los hotfixes creados inicialmente o validados antes de que se actualice el entorno de producción. 4. Hotfix Process Review: Estamos evaluando mejoras en el proceso global de hotfix para reducir la dependencia de los hotfixes de producción y reducir aún más el riesgo de cambios correctivos necesarios que no se incluyen en futuras versiones de producción. 5. Mejora de la vigilancia de las aplicaciones: se están implementando monitoreos y alertas adicionales a nivel de aplicación para mejorar la detección temprana de fallos intermitentes y condiciones de error anormales antes de que resulten en un impacto más amplio del cliente.

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

1. 24 de septiembre de 2026 a las 10:11 UTCinvestigating

   Descripción del incidente: Identificamos un problema que afecta al procesamiento del inventario en Flexera One IT Asset Management (ITAM) en la región del NAM, impactando un subconjunto de clientes. Como resultado, algunas subidas de inventario no se están procesando con éxito, lo que hace que los datos de inventario mostrados en Flexera One ITAM sean retrasados y no reflejen el inventario cargado más recientemente. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente la cuestión para identificar la causa subyacente e implementar una solución. Seguimos vigilando de cerca la situación y proporcionaremos más actualizaciones a medida que avance la investigación.

2. 24 de septiembre de 2026 a las 12:27 UTCinvestigating

   Further investigation indicates that the issue appears to be associated with the service responsible for transferring inventory data to ITAM. Nuestros equipos técnicos continúan investigando la cuestión y están trabajando para identificar la causa subyacente y determinar la rehabilitación adecuada. Seguiremos proporcionando nuevas actualizaciones a medida que se disponga de más información.

3. 24 de septiembre de 2026 a las 14:32 UTCmonitoring

   Nuestro equipo realizó reiniciamientos de pod dirigidos, tras lo cual el procesamiento de archivos de inventario se reanudó con éxito para todos los clientes afectados. El procesamiento exitoso ha sido validado a través de registros y gráficos de monitoreo. Seguiremos vigilando de cerca los servicios para garantizar la estabilidad continua y proporcionar nuevas actualizaciones a medida que se disponga de información adicional.

4. 24 de septiembre de 2026 a las 18:42 UTCmonitoring

   Nuestros equipos técnicos siguen observando con éxito el procesamiento de archivos de inventario y la operación estable de servicios tras las acciones de recuperación. La validación mediante monitoreo confirma que los archivos de inventario afectados están procesando con éxito. La recuperación atrasada está en curso, con las colas de procesamiento de inventarios continúan disminuyendo a medida que se procesan los archivos. Los equipos técnicos están monitoreando activamente el progreso de la recuperación y la salud general de los servicios, mientras que el atraso restante se aclara. Seguiremos proporcionando actualizaciones a medida que avance la recuperación.

5. 24 de septiembre de 2026 a las 20:32 UTCresolved

   This incident was inadvertently marked as resolved with an update intended for a separate incident. La recuperación del procesamiento de los inventarios sigue siendo objeto de vigilancia, ya que el atraso sigue siendo claro. Los equipos técnicos siguen observando el procesamiento exitoso de archivos y la operación de servicio estable. Las actualizaciones de recuperación en curso y la vigilancia atrasada continuarán con el incidente recién creado: https://status.flexera.com/incidents/vztp63wmxjb Proporcionaremos nuevas actualizaciones a medida que continúen los progresos de recuperación atrasados y la validación de la recuperación.

6. 23 de octubre de 2026 a las 17:25 UTCpostmortem

   **Descripción:** Flexera One - IT Asset Management - NAM - Inventory Processing Delays Following Production Activity **Tiempo:** 22 de septiembre de 2026, 7:05 PM PDT - 25 de septiembre de 2026, 5:30 AM PDT ** Resumen del incidente** El 24 de septiembre de 2026, equipos técnicos comenzaron a investigar informes de actualizaciones de inventario retrasadas que afectaron a un subconjunto de clientes utilizando Flexera One IT Asset Management \(ITAM\) en la región de Norteamérica \(NAM\). Aunque los archivos de inventario se estaban cargando con éxito y seguían disponibles, algunos clientes experimentaron retrasos en el procesamiento de estos archivos, impidiendo que la última información de inventario se reflejara en la aplicación. La información de estado de Beacon mostrada en ITAM también podría haber sido anticuada para los clientes afectados. El procesamiento de inventario continuó normalmente para otros clientes. La cuestión se produjo después de la actividad de liberación de producción ITAM 2026R1.3 el 22 de septiembre de 2026. La investigación identificó una interrupción en el proceso responsable de transferir archivos de inventario cargados a los servicios de procesamiento de inventarios de ITAM. Si bien los archivos afectados seguían disponibles en almacenamiento, no estaban siendo remitidos para su procesamiento. Los equipos técnicos también observaron errores elevados de aplicación durante la investigación, aunque estos errores no se establecieron concluyentemente como causa de la interrupción. Los equipos técnicos realizaron un reinicio específico del componente de servicio afectado, restaurando la transferencia de archivos de inventario y permitiendo que el procesamiento se reanudara para clientes previamente afectados. Se ha habilitado la tala de diagnóstico adicional para apoyar nuevas investigaciones. Sin embargo, durante la interrupción se había acumulado un atraso considerable de los archivos de inventario y se requería tiempo adicional para procesarlos. Tras la restauración del procesamiento, los equipos técnicos continuaron vigilando la actividad de inventario y el atraso acumulado. Para el viernes 25 de septiembre de 2026, aproximadamente a las 5:30 AM PDT, el atraso relacionado con incidentes había retornado a niveles operativos normales, confirmando la recuperación del procesamiento del inventario. *Causa real* El incidente fue causado por una interrupción del flujo de trabajo de procesamiento de inventarios tras la actividad de lanzamiento de producción ITAM 2026R1.3 en la región del NAM. Aunque los archivos de inventario fueron cargados con éxito y permanecieron disponibles en almacenamiento, el componente responsable de enviar estos archivos al procesamiento de ITAM dejó de transferir datos de inventario para un subconjunto de clientes. Como resultado, los archivos de inventario afectados no se procesaron, retrasando las actualizaciones de inventario. La cuestión no afectaba a todos los clientes, ya que el procesamiento de inventario continuaba normalmente para otras organizaciones. Investigación identificó errores de aplicación elevados y comportamiento indicando que el componente de procesamiento afectado no se estaba recuperando como se esperaba. La condición técnica precisa responsable de la interrupción parcial sigue siendo investigada. Un reinicio específico del componente de servicio afectado restaurado procesamiento de inventario para clientes afectados. Posteriormente se tramitó el atraso acumulado, lo que permitió que las actualizaciones del inventario volvieran a niveles normales. ** Acciones de rehabilitación** Durante la respuesta al incidente se adoptaron las siguientes medidas: 1. **Iniciación de la investigación accidental:** Los equipos técnicos investigaron los informes de actualizaciones de inventario retrasadas que afectaron a un subconjunto de clientes de la región del MNOAL y examinaron el flujo de trabajo de procesamiento de inventarios para determinar el alcance de la cuestión. 2. ** Interrupción de Procesamiento Inventario:** La investigación confirmó que los archivos de inventario cargados estaban disponibles en almacenamiento, pero no estaban siendo enviados a los servicios de procesamiento para los clientes afectados. 3. **Afectado componente de servicio Un reinicio específico del componente de servicio afectado restauró la transferencia de archivos de inventario y permitió que el procesamiento reanudara para clientes previamente afectados. 4. **Tabla de diagnóstico adicional:** Se permitió obtener más información técnica y apoyar la investigación continuada de la interrupción del proceso subyacente. 5. **Inventory Backlog Recovery Monitored:** Los equipos técnicos supervisaron el atraso acumulado del inventario tras la restauración del procesamiento y confirmaron que los archivos de inventario se estaban procesando con éxito. 6. ** Recuperación de servicios validada:** Los equipos técnicos confirmaron que el atraso relacionado con incidentes había regresado a los niveles operativos normales antes del 25 de septiembre y que el procesamiento de inventario seguía siendo estable. **Medidas preventivas completas** Tras el incidente, realizamos una retrospectiva para revisar el fallo de procesamiento parcial de inventarios, la arquitectura existente de entrega de inventarios, la información de diagnóstico disponible y las oportunidades de mejorar la fiabilidad de procesamiento y la visibilidad de fallos. Se están llevando a cabo las siguientes acciones correctivas y actividades de mejora: 1. ** Mejora de la Arquitectura de Procesamiento Inventario:** Se prevé trabajar para simplificar la integración de procesamiento de inventarios permitiendo a ITAM recuperar archivos de inventario cargados directamente desde la capa de almacenamiento en lugar de depender del servicio de reenvío intermedio existente. Este cambio eliminará una dependencia adicional de la vía de procesamiento y proporcionará un mayor control sobre el procesamiento, la gestión atrasada, la capacidad y la recuperación. 2. ** Diagnósticos mejorados de falla:** La tala diagnóstica y la telemetría necesarias para captar el estado de servicio pertinente durante un fallo de procesamiento parcial de inventario se evaluarán y mejorarán según proceda. Esto proporcionará información técnica mejorada para apoyar la determinación de la causa raíz si se repite una condición similar.

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

1. 23 de septiembre de 2026 a las 10:05 UTCinvestigating

   Descripción del incidente: Actualmente estamos investigando un problema que afecta el acceso a nuestros servicios en el entorno de la UE. Los clientes de la UE pueden experimentar problemas de acceso al servicio. Prioridad: P1 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente la cuestión como prioridad y trabajando para restaurar el servicio normal lo antes posible.

2. 23 de septiembre de 2026 a las 10:24 UTCmonitoring

   Los servicios han sido restaurados, y el acceso está funcionando como se espera. Nuestros equipos están monitoreando estrechamente la plataforma para garantizar la estabilidad continua.

3. 23 de septiembre de 2026 a las 11:43 UTCresolved

   Nuestros equipos han seguido vigilando la plataforma y no han observado ninguna repetición del problema. Este incidente ya está resuelto. Continuaremos nuestra investigación para determinar la causa subyacente e identificar medidas correctivas apropiadas. En el informe posterior a la mañana se proporcionarán más detalles.

4. 26 de octubre de 2026 a las 10:40 UTCpostmortem

   **Descripción:** Flexera Uno - UE - Acceso no disponible **Tiempo:** * 24 de septiembre de 2026, 2:51 AM PDT al 24 de septiembre de 2026, 3:18 AM PDT * 25 de septiembre de 2026, 3:50 AM al 25 de septiembre de 2026, 4:30 AM PDT ** Resumen del incidente** El 24 de septiembre de 2026 a las 2:51 AM PDT, los clientes experimentaron fallos de inicio de sesión al intentar acceder al entorno Flexera One EU Production. La investigación confirmó la degradación de los servicios de Identidad y Gestión de Accesos de la UE, lo que impidió que los clientes accedieran a la plataforma. La investigación identificó un aumento significativo de las conexiones de bases de datos asociadas con el tráfico elevado de una sola organización. Further analysis determined that repeated downstream requests generated by other services also contributed to the increased load on the autation and access-control services. A las 3:18 AM PDT, la funcionalidad de inicio de sesión del cliente fue restaurada sin intervención técnica directa, y la plataforma volvió a la operación normal. El 25 de septiembre de 2026 aproximadamente a las 3:50 AM PDT, se observó otro aumento de las conexiones de bases de datos, asociado con el tráfico elevado de la misma organización. El aumento de la carga continuó durante aproximadamente 40 minutos. En respuesta, se permitió que el servicio de gestión de recursos aumentara la capacidad y mejorara la estabilidad de las plataformas. *Causa real* El incidente fue causado por un aumento inesperado del tráfico que impuso una demanda excesiva en los servicios de autenticación de la UE y las conexiones de bases de datos asociadas. El aumento de la carga afectó a los servicios responsables de la tramitación de solicitudes de autenticación, lo que dio lugar a fallos de acceso al cliente dentro del entorno de producción de la UE. Las solicitudes reiteradas de otros servicios a los servicios de autenticación y control de acceso contribuyeron aún más a la carga elevada. Además, el aumento automático no estaba habilitado para el servicio de gestión de recursos, limitando su capacidad de aumentar dinámicamente la capacidad de respuesta a una mayor demanda. Las lagunas en la vigilancia y alerta proactivas también limitaron la capacidad de identificar la degradación antes de que los clientes experimentaran fallos de acceso. ** Acciones de rehabilitación** Nuestros equipos realizaron las siguientes acciones para restaurar los servicios a la normalidad: * El incidente del 24 de septiembre resuelto sin intervención de ingeniería directa, y la funcionalidad de acceso al cliente fue restaurada a las 3:18 AM PDT. * El 25 de septiembre, se permitió que el servicio de gestión de recursos aumentara la capacidad de respuesta a la demanda elevada. * El equipo siguió vigilando las conexiones de bases de datos y la salud de los servicios para evaluar la estabilidad de las plataformas. **Medidas preventivas completas** Se han identificado las siguientes medidas y se están trabajando para reducir la probabilidad de recurrencia y mejorar la resiliencia de los servicios: * Escalada automática: Revisar la configuración de autoescalamiento para el servicio de gestión de recursos en todas las regiones de producción, para asegurar que la capacidad se ajuste a los cambios de volumen de trabajo. * Gestión de la capacidad de base de datos: Revisar la configuración de la conexión de la base de datos y asegurar que el escalado de servicios permanezca dentro de la capacidad de conexión disponible de la base de datos. * Supervisión y alerta proactivas: Revisar e introducir alertas para el crecimiento anormal de la conexión de bases de datos, la saturación de conexiones, latencia de servicios, tasas de error y utilización de recursos. * Supervisión del tráfico: Mejorar la visibilidad en los patrones de tráfico a nivel de organización para identificar puntos de solicitud inusuales antes de afectar a otros clientes. * Gestión del tráfico: Evaluar los controles adecuados de limitación de tarifas y de reducción de velocidad para evitar que un tráfico excesivo de una sola organización afecte a la disponibilidad en toda la plataforma. * Pruebas de carga y capacidad: Realizar pruebas de carga utilizando patrones de tráfico representativos del incidente para validar el rendimiento de los servicios y la capacidad de base de datos bajo demanda elevada.

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

1. 23 de septiembre de 2026 a las 6:51 UTCinvestigating

   Descripción del incidente: Actualmente estamos investigando un problema que afecta al entorno de producción de Flexera One IT Asset Management (ITAM) en América del Norte, que sigue sin estar disponible debido al mantenimiento programado que se extiende más allá de la ventana de mantenimiento planificada. La actividad de mantenimiento sigue en curso mientras se completa la reconstrucción de una base de datos. Prioridad: P1 Actividad de restauración: Nuestros equipos técnicos están trabajando activamente para completar la actividad de mantenimiento restante y restaurar el servicio lo antes posible. El ETA para la reconstrucción de la base de datos es de aproximadamente 2 horas. Nuestros equipos están vigilando de cerca el progreso y proporcionarán más detalles a medida que estén disponibles.

2. 23 de septiembre de 2026 a las 9:15 UTCinvestigating

   Nuestros equipos técnicos han completado una fase importante de la actividad de mantenimiento en curso y continúan con el procesamiento restante necesario para completar la actualización. El proceso está tomando más tiempo de lo estimado originalmente. El medio ambiente sigue sin estar disponible mientras estas actividades están en marcha. Los equipos están monitoreando activamente las opciones restantes de procesamiento y evaluación para restaurar el servicio lo antes posible. Se proporcionarán actualizaciones adicionales a medida que avance la actualización y el cronograma de restauración se vuelve más claro.

3. 23 de septiembre de 2026 a las 11:47 UTCmonitoring

   La actualización se ha completado con éxito. Nuestros equipos están trabajando para restaurar los servicios y realizar la validación posterior al despliegue.

4. 23 de septiembre de 2026 a las 13:02 UTCmonitoring

   La actualización se ha completado con éxito, y el sitio ahora está de vuelta en línea. Nuestro equipo está realizando cheques de validación final para confirmar la estabilidad del servicio antes de declarar resuelto el incidente.

5. 23 de septiembre de 2026 a las 15:57 UTCresolved

   El servicio ha sido restaurado y funciona normalmente. Following recovery, technical teams completed extended monitoring and validation activities and have confirmed stable operation. El incidente se considera resuelto.

6. 30 de septiembre de 2026 a las 16:02 UTCpostmortem

   **Descripción:** Flexera One – IT Asset Management – North America – Service Invailability Following 2026R1.3 Mantenimiento **Tiempo:** 22 de septiembre de 2026, 9:00 PM PDT – 23 de septiembre de 2026, 5:47 AM PDT ** Resumen del incidente** El 22 de septiembre de 2026, Flexera realizó la versión prevista de producción de 2026R1.3 para Flexera One IT Asset Management en la región de América del Norte. La mejora progresó con éxito en la gran mayoría de las bases de datos dentro del medio ambiente. Sin embargo, cuando la ventana de mantenimiento programada concluyó a las 9:00 PM PDT, se mantuvo en marcha una operación de migración de bases de datos necesaria. Debido a que el entorno de producción no puede ser restaurado hasta que se complete la migración, la gestión de bienes de tecnología de la información sigue sin estar disponible más allá del período de mantenimiento previsto. La migración restante requería una reconstrucción de un gran índice de bases de datos con un volumen significativo de datos. La operación se convirtió en el camino crítico para completar la liberación y tomó sustancialmente más tiempo de lo previsto. Después de completar la etapa inicial de procesamiento de índices, la base de datos todavía necesitaba realizar actividades adicionales de clasificación y creación de índices. Esta labor continuó durante varias horas y prorrogó la duración general de la migración. Durante la investigación, los equipos técnicos evaluaron las opciones de recuperación disponibles, entre ellas si la base de datos afectada podía separarse temporalmente de la vía migratoria para permitir que el resto del medio ambiente regresara al servicio. Debido a la etapa del despliegue y a la labor adicional de recuperación que habría requerido, la vía de recuperación más fiable era permitir que la operación de la base de datos terminara antes de restaurar el medio ambiente. Una vez terminada la migración de bases de datos, los equipos técnicos comenzaron a restaurar los servicios de aplicaciones y apoyo. Durante la puesta en marcha, se encontró un problema adicional de recuperación de servicios que requería intervención manual antes de que pudiera continuar la restauración. Tras la rehabilitación, se restablecieron con éxito los servicios de aplicaciones y plataformas restantes. Los equipos técnicos completaron las actividades de validación, confirmaron el acceso al cliente y realizaron un seguimiento prolongado para verificar la estabilidad del servicio. El impacto del cliente terminó el 23 de septiembre de 2026, a las 5:47 AM PDT. *Causa real* La salida fue causada por una discrepancia de configuración del índice de base de datos que se identificó durante la migración 2026R1.3, lo que dio lugar a una operación de reconstrucción de un índice grande que superó sustancialmente la ventana de mantenimiento prevista. La investigación posterior al incidente determinó que un índice dentro de la base de datos afectada no coincidía con la estructura de la base de datos prevista en la versión actual. El índice se había recreado anteriormente utilizando una definición anterior que no incorporaba un cambio de diseño de bases de datos posterior. Durante el despliegue de 2026R1.3, el proceso de migración identificó esta diferencia e inició la operación de base de datos necesaria para armonizar el índice con la definición actual de la base de datos. Debido al tamaño excepcionalmente grande del conjunto de datos involucrados, la reconstrucción resultante se convirtió en una operación de larga duración y intensivo de recursos que superó significativamente la ventana de mantenimiento prevista. Una vez que la reconstrucción estaba en marcha, la duración restante de la tramitación no podía predecirse de forma fiable, lo que dificultaba proporcionar una estimación precisa de la terminación mientras continuaba la operación. ** Acciones de rehabilitación** Durante la respuesta al incidente se adoptaron las siguientes medidas: * Se monitoreó la recuperación de índices: el índice reconstruyó y las actividades de actualización de bases de datos restantes se supervisaron continuamente mediante la terminación. * Opciones de recuperación Evaluadas: Se evaluaron los enfoques de restauración disponibles para determinar el camino más seguro y fiable para devolver el entorno de producción al servicio. * Actualización de bases de datos completado: El índice de reconstrucción y las actividades de actualización de bases de datos restantes se completaron antes de iniciar la restauración de aplicaciones. * Servicios de Aplicación y Apoyo Restaurados: Se restauraron los servicios de aplicaciones y apoyo. Se realizaron acciones de recuperación orientadas cuando se encontró una cuestión adicional de puesta en marcha de servicios. * Recuperación de servicio validada: Se confirmó el acceso al cliente y la funcionalidad de aplicación, se revisó el procesamiento de antecedentes restantes y se completó la vigilancia ampliada para verificar la operación estable. **Medidas preventivas completas** Flexera reconoce la importancia y la duración de esta salida y el impacto que tuvo en los clientes de la región de Norteamérica. Se ha completado un análisis completo de las causas profundas y una retrospectiva interfuncional, y se han determinado las siguientes medidas preventivas como parte de la labor de mejora en curso: 1. Validación del procedimiento de base de datos: Los equipos técnicos están evaluando cómo se revisan y mantienen los procedimientos de remediación de bases de datos para asegurar que se mantengan alineados con los requisitos actuales del producto a medida que evoluciona la plataforma. 2. Verificación previa al despliegue: se están evaluando los procesos de validación de la liberación para determinar cómo pueden identificarse y evaluarse las diferencias de configuración de la base de datos inesperadas antes de que comience el mantenimiento de la producción. 3. Evaluación de las operaciones de alto impacto: Los equipos técnicos están evaluando cómo pueden identificarse las operaciones de base de datos de larga duración o de gran densidad de recursos durante la preparación de la versión para que su duración prevista y sus efectos operacionales puedan entenderse mejor antes del despliegue. 4. Lectura de lanzamiento y planificación de la recuperación: se están revisando las prácticas de preparación de lanzamientos y planificación de la recuperación para mejorar la visibilidad en actividades que pueden afectar significativamente la duración del despliegue y los plazos de restauración de servicios. La prestación de servicios fiables y resilientes sigue siendo una prioridad. Las conclusiones del análisis de causas profundas y la retrospectiva completadas se están incorporando en mejoras técnicas y operacionales destinadas a reducir la probabilidad de recurrencia y fortalecer la planificación y ejecución de futuras actividades de mantenimiento.

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

1. 22 de septiembre de 2026 a las 5:56 UTCinvestigating

   Descripción del incidente: Actualmente estamos investigando un problema que afecta a un subconjunto de nuestros clientes utilizando Snow Atlas en la región de Australia. Los clientes afectados pueden experimentar retrasos en ver la información más reciente de la computadora y la ingestión de datos también pueden ser impactados. Prioridad: P2 Actividad de Restauración: Se identificó una cuestión anterior relacionada con el DNS y se ha resuelto. Sin embargo, se están observando errores adicionales. Nuestros equipos técnicos están investigando activamente estos errores para determinar la causa subyacente y restaurar el procesamiento normal. Seguiremos evaluando el impacto y proporcionando nuevas actualizaciones a medida que se disponga de información adicional.

2. 22 de septiembre de 2026 a las 7:19 UTCinvestigating

   Nuestros equipos han realizado reiniciamientos de servicios dirigidos, que han mejorado las demoras de procesamiento. La vigilancia indica que los datos de inventario se están actualizando con éxito. Los errores restantes siguen siendo investigados, y nuestros equipos están trabajando para identificar la causa subyacente e implementar una solución permanente.

3. 22 de septiembre de 2026 a las 10:15 UTCmonitoring

   Las medidas de remediación han resuelto los retrasos en el procesamiento y las cuestiones relativas a los datos. Nuestros equipos técnicos siguen investigando algunas cuestiones residuales. Los equipos están vigilando los servicios y continuarán recogiendo y revisando los registros en las próximas 24 horas para apoyar la investigación. Seguiremos vigilando de cerca los servicios y proporcionaremos más actualizaciones a medida que se disponga de más información.

4. 23 de septiembre de 2026 a las 7:05 UTCresolved

   Nuestros equipos continuaron vigilando los servicios durante la noche y confirmaron que no se han observado nuevos problemas. También se completaron con éxito los cheques adicionales. Este incidente está siendo resuelto. En el informe posterior a la mortem se proporcionará más información sobre la causa y las medidas adoptadas.

5. 13 de octubre de 2026 a las 12:49 UTCpostmortem

   **Descripción:** Snow Atlas- APAC - Retrasos en la ingestión y procesamiento de datos **Tiempo:** 21 de septiembre de 2026, 5:48 PM PDT al 22 de septiembre de 2026, 3:15 AM PDT ** Resumen del incidente** El lunes 21 de septiembre de 2026, a las 5:48 PM PDT, un problema afectó a múltiples inquilinos de Snow Atlas en la región de Australia Oriental \(AE\), dando lugar a retrasos en las actualizaciones de datos de inventario. Los clientes afectados experimentaron información sobre dispositivos obsoletos en la página de Computadoras, mientras que los Extensores de Nieve exhibieron un estado de “Avanzando con Errores”. También se observaron errores durante la ingestión de datos. La investigación identificó un registro anticuado del DNS asociado con infraestructuras previamente descompuestas en la región sudoriental de Australia. Este registro interfirió con la conectividad al medio ambiente de Australia oriental, impidiendo que los datos de inventario se procesaran según lo previsto. Se eliminó el registro DNS anticuado, permitiendo que el tráfico llegara al punto final correcto y permitiendo que se reanudaran las actualizaciones de la exploración de inventarios. Tras el cambio, los recuentos de inventario comenzaron a progresar, y los estados de servicio de conectividad afectados regresaron a la normalidad el 22 de septiembre de 2026, a las 3:15 AM PDT. Tras un largo período de vigilancia de la noche a la mañana, los servicios de conectividad permanecieron estables, y la cuestión fue declarada resuelta el 23 de septiembre a las 12:05 AM PDT. No se han informado otras cuestiones, y la infraestructura sudeste de Australia utilizada anteriormente se ha desmantelado totalmente. *Causa real* The incident was caused by an outdated DNS record that remained after the decommissioning of infrastructure in the Australia Southeast region. Este registro dispuso que el tráfico fuera del punto final correcto para el entorno de Australia oriental, lo que interrumpía la conectividad necesaria para el procesamiento de datos de inventario. Como resultado, las actualizaciones de inventario se retrasaron, y los clientes afectados no pudieron recuperar la información más reciente del dispositivo. El registro obsoleto fue eliminado, restableciendo la conectividad al punto final correcto y permitiendo que el procesamiento del inventario se reanudara. ** Acciones de rehabilitación** Nuestros equipos realizaron las siguientes acciones para restaurar los servicios a la normalidad: * Identificado y eliminado el registro DNS desactualizado asociado con la infraestructura descompuesta anteriormente. * Conectividad restaurada con el punto final Australia Oriental correcto. * Verificado que las actualizaciones del inventario y los recuentos de inventario estaban progresando. * Supervisó el medio ambiente para confirmar la estabilidad del servicio. * Confirmó que los estados de servicio de conectividad de nieve regresaron posteriormente a la normalidad y no se notificaron otros problemas. **Medidas preventivas completas** * Revisar la limpieza de registros DNS durante la descomposición de infraestructura para asegurar que se eliminan los registros obsoletos. * Mejorar las comprobaciones posteriores a la baja para identificar los registros que permanecen después de la eliminación de los recursos.

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

1. 18 de septiembre de 2026 a las 13:03 UTCinvestigating

   Descripción del incidente: Estamos investigando una cuestión que afecta al procesamiento de datos de inventario en los entornos de producción de la UE y APAC. Los clientes pueden observar retrasos en las actualizaciones de inventario, lo que da lugar a datos de inventario que no reflejan la actividad de importación más reciente. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos están investigando activamente la cuestión, validando el alcance del impacto y trabajando con dependencias pertinentes para restaurar el procesamiento normal del inventario. Se proporcionarán más actualizaciones a medida que se disponga de más información.

2. 18 de septiembre de 2026 a las 13:50 UTCidentified

   Nuestros equipos técnicos han rastreado la cuestión a un despliegue reciente y han implementado acciones de rehabilitación. La validación inicial indica que se ha reanudado el procesamiento de inventarios y los equipos técnicos están monitoreando activamente la actividad de procesamiento y la recuperación atrasada. Continuamos validando la recuperación en todos los entornos afectados y proporcionaremos más actualizaciones a medida que se disponga de más información.

3. 18 de septiembre de 2026 a las 14:34 UTCidentified

   Los equipos técnicos han completado las actualizaciones de configuración necesarias, y los datos de inventario siguen siendo tratados con éxito. Se ha asignado una capacidad adicional de procesamiento para acelerar la recuperación atrasada, y los equipos técnicos están vigilando activamente la reducción de los rendimientos y los retrasos en los entornos afectados. Las actividades de recuperación siguen en curso y se proporcionarán nuevas actualizaciones a medida que continúe el procesamiento atrasado.

4. 18 de septiembre de 2026 a las 14:39 UTCmonitoring

   El procesamiento de datos de inventario continúa recuperándose, y los equipos técnicos observan una tendencia descendente en el volumen atrasado. Sigue existiendo una capacidad de procesamiento adicional y se está vigilando de cerca el progreso de la recuperación en todos los entornos afectados. Seguiremos monitoreando la reducción atrasada y proporcionaremos nuevas actualizaciones a medida que avance la recuperación.

5. 18 de septiembre de 2026 a las 18:52 UTCmonitoring

   El procesamiento de datos de inventario continúa después de la rehabilitación implementada anteriormente. Los equipos técnicos están monitoreando activamente el procesamiento de la producción y la recuperación atrasada en los entornos afectados. Los equipos técnicos siguen evaluando el progreso de la recuperación y las medidas adicionales que puedan ayudar a acelerar el procesamiento atrasado. Se proporcionarán nuevas actualizaciones a medida que avance la recuperación.

6. 18 de septiembre de 2026 a las 19:49 UTCmonitoring

   La recuperación atrasada se ha completado en la APAC tras la rehabilitación aplicada anteriormente, y el procesamiento de datos de inventario ha regresado a los niveles previstos en la región. Continúan las actividades de recuperación en la UE, donde los equipos técnicos están monitoreando el procesamiento mediante la reducción de rendimientos y retrasos. Se están evaluando medidas adicionales de recuperación para apoyar el procesamiento atrasado a medida que avanza la recuperación.

7. 18 de septiembre de 2026 a las 21:55 UTCmonitoring

   Los esfuerzos de recuperación continúan en la UE, y los equipos técnicos están observando la reducción continua del retraso restante. Se han aplicado nuevas optimizaciones de recuperación para apoyar el procesamiento atrasado en la UE, y los equipos técnicos siguen vigilando el rendimiento y el progreso general de la recuperación. Se proporcionarán nuevas actualizaciones a medida que continúen los progresos.

8. 19 de septiembre de 2026 a las 11:07 UTCmonitoring

   La recuperación sigue progresando, y el retraso restante disminuye constantemente. Otras optimizaciones aplicadas en el entorno de la UE están apoyando el procesamiento atrasado de manera eficaz. Nuestros equipos siguen vigilando de cerca el progreso de la recuperación y proporcionarán nuevas actualizaciones según proceda.

9. 19 de septiembre de 2026 a las 19:09 UTCmonitoring

   Los esfuerzos de recuperación continúan en la UE, y los equipos técnicos están observando una reducción continua de los retrasos tras las optimizaciones aplicadas anteriormente. Sobre la base de las tendencias actuales de recuperación, se han reducido considerablemente los niveles atrasados y siguen avanzando en la dirección prevista. Se proporcionarán nuevas actualizaciones a medida que continúen los progresos.

10. 20 de septiembre de 2026 a las 19:55 UTCresolved

    Los equipos técnicos han confirmado que el procesamiento de datos de inventario en la UE ha regresado a una operación normal tras la rehabilitación implementada anteriormente. La cuestión se trazó a una cuestión de configuración del despliegue que afectaba al procesamiento de datos del inventario. Se aplicaron las actualizaciones de configuración necesarias, restaurando el procesamiento normal. Tras la validación y la supervisión ampliada, la recuperación atrasada en la UE ha finalizado y el procesamiento de inventario sigue siendo estable tanto en la UE como en la APAC. Este incidente se considera resuelto.

11. 23 de octubre de 2026 a las 17:20 UTCpostmortem

    **Descripción:** Flexera One - IT Asset Management - EU & APAC - Inventory Processing Delays Following a Deployment Configuration Issue **Tiempo:** 16 de septiembre de 2026, 2:00 PM PDT - 20 de septiembre de 2026, 9:52 AM PDT ** Resumen del incidente** El viernes 18 de septiembre de 2026, equipos técnicos comenzaron a investigar informes de actualizaciones de inventario retrasadas que afectaron a clientes de Flexera One IT Asset Management \(ITAM\) en las regiones de Europa \(EU\) y Asia-Pacífico \(APAC\). La información actualizada sobre los inventarios no se reflejaba en la aplicación, y algunos clientes informaron de que sus últimos datos de inventario disponibles seguían datando del 16 de septiembre. La cuestión afectaba al procesamiento de inventario en lugar de la disponibilidad general de la plataforma ITAM. El análisis inicial indicó que los servicios de procesamiento de inventarios parecían saludables, pero los archivos de inventario entrantes no estaban progresando a través del flujo de trabajo de procesamiento previsto. La investigación posterior trazó la interrupción a un despliegue realizado el 16 de septiembre, durante el cual un problema de configuración afectó a los servicios responsables de la elaboración de datos de inventario. Los equipos técnicos identificaron y corrigieron la configuración del despliegue, lo que permitió reanudar el procesamiento del inventario. Sin embargo, durante la interrupción se había acumulado un atraso considerable de los archivos de inventario y se requería tiempo adicional para procesarlos. El procesamiento de inventario se recuperó primero en APAC, donde el atraso acumulado fue despejado el 18 de septiembre a aproximadamente 12:21 PM PDT. La región de la UE necesita tiempo adicional de recuperación debido al volumen de archivos pendientes. Los equipos técnicos ajustaron la configuración de la capacidad de procesamiento y siguieron vigilando el retraso a medida que se procesaron los archivos de inventario. El atraso de la UE restante fue totalmente despejado el 20 de septiembre a aproximadamente 9:52 AM PDT. La vigilancia posterior confirmó que el procesamiento de inventario había retornado a niveles operativos normales. *Causa real* El incidente fue causado por un problema de configuración del despliegue introducido durante una actualización del 16 de septiembre a los servicios de procesamiento de inventarios. En el momento del despliegue, la infraestructura de procesamiento de inventarios estaba en transición entre los entornos de aplicación, con distintos servicios necesarios para mantenerse activos en cada entorno dependiendo de la región. Esto aumentó la complejidad de mantener la configuración correcta de producción, y la configuración de servicio necesaria no se mantuvo correctamente durante el despliegue. Como resultado de ello, el flujo de trabajo de procesamiento de inventarios se interrumpió en las regiones de la Unión Europea y de la APAC, lo que impidió que los archivos de inventario se procesaran y retrasara las actualizaciones de datos de inventario. Una vez que se corrigió la configuración, se reanudó el procesamiento de inventario, con el atraso acumulado que requería tiempo adicional para procesar antes de que se restablecieran completamente los niveles operativos normales. ** Acciones de rehabilitación** Durante la respuesta al incidente se adoptaron las siguientes medidas: 1. **Iniciación de la investigación accidental:** Los equipos técnicos investigaron los informes de actualizaciones tardías de los inventarios en las regiones de la UE y la APAC y examinaron el flujo de trabajo de procesamiento de inventarios para determinar la fuente de la interrupción. 2. ** Número de configuración del despliegue identificado:** La investigación rastreó la interrupción del despliegue del 16 de septiembre e identificó una configuración incorrecta de servicios que afectaba al procesamiento de inventario en las regiones afectadas. 3. **Configuración de producción Corregido:** Se aplicaron las actualizaciones de configuración necesarias para restaurar los servicios de procesamiento de inventarios afectados, lo que permitió que los archivos de inventario entrantes reanudaran el procesamiento. 4. **Inventory Backlog Recovery Initiated:** Los equipos técnicos supervisaron los archivos de inventario acumulados y ajustaron los recursos de procesamiento disponibles para apoyar la recuperación atrasada tras la restauración del flujo de trabajo de procesamiento. 5. ** Optimización de la productividad:** Durante la recuperación de la Unión Europea, los equipos técnicos determinaron las limitaciones de capacidad de procesamiento en el marco del aumento del volumen de trabajo y el acuerdo de procesamiento ajustado para mejorar el rendimiento manteniendo la estabilidad de los servicios. 6. ** Recuperación de servicios validada:** Los equipos técnicos confirmaron que el atraso de la APAC había despejado el 18 de septiembre, seguido de la recuperación atrasada total de la UE el 20 de septiembre. La vigilancia continua comprobó que el procesamiento de inventario había retornado a niveles operativos normales. **Medidas preventivas completas** Following the incident, we conducted a retrospective to review the deployment configuración issue, differences between application environments, inventory-processing monitoring capabilities, and opportunities to improve deployment validation and operational visibility. Se han completado o están en marcha las siguientes medidas correctivas y actividades de mejora: 1. **Regional Service Configuration Management:** Se ha aplicado una lista regional de configuración de servicios para documentar y mantener las configuraciones de servicios necesarias en los diferentes entornos de despliegue, reduciendo el riesgo de incoherencias de configuración durante futuras versiones. 2. ** Mejoras de la validación del despliegue:** Se ha puesto en práctica una lista de verificación para el despliegue a fin de verificar que los servicios necesarios de procesamiento de inventario se ejecutan en los entornos apropiados durante las actividades de despliegue. 3. ** Mejora de la vigilancia del procesamiento de los inventarios** Se han puesto en práctica nuevas actividades de vigilancia y alerta para detectar las interrupciones en el procesamiento de inventarios antes y facilitar una investigación y recuperación más rápidas. 4. ** Visibilidad de procesamiento mejorada:** Se han implementado tableros de control para dar mayor visibilidad a patrones de respuesta a aplicaciones anormales, incluyendo errores relacionados con la capacidad de procesamiento. Estas mejoras ya han apoyado la detección y recuperación anteriores durante las cuestiones posteriores de procesamiento. 5. **Simplificación del medio ambiente de producción:** La labor en curso para consolidar el modelo de despliegue reducirá la complejidad operacional asociada al mantenimiento de diferentes configuraciones de servicios en entornos y regiones, ayudando a reducir el riesgo de interrupciones de procesamiento similares relacionadas con la configuración.

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

1. 16 de septiembre de 2026 a las 9:04 UTCidentified

   Descripción del incidente: Actualmente estamos experimentando un problema que afecta al sitio de la Comunidad Flexera. Debido a una salida en curso que afecta a un proveedor de servicios de terceros, los clientes pueden ser incapaces de acceder al portal de la Comunidad Flexera o pueden experimentar comportamientos intermitentes e irremisibles. Además, los clientes pueden ser incapaces de crear, actualizar o interactuar con casos de apoyo a través del sitio de la Comunidad. Los correos electrónicos enviados a [email protected] durante este período no pueden ser recibidos o procesados hasta que se haya resuelto el outage subyacente. Esta salida del proveedor de servicios de terceros también impacta la capacidad de monitoreo proactiva para los equipos de soporte Spot para detectar cualquier problema del entorno del cliente junto con un widget de chatbot dentro de la consola Spot también. Prioridad: P3 Actividad de Restauración: Nuestros equipos técnicos están monitoreando activamente la situación y trabajando con el proveedor de terceros para realizar un seguimiento de los esfuerzos de restauración. Seguiremos evaluando el impacto del cliente y proporcionaremos nuevas actualizaciones a medida que se disponga de información adicional.

2. 16 de septiembre de 2026 a las 12:31 UTCidentified

   El proveedor de servicios ha validado con éxito la fijación en un entorno de prueba y ha comenzado a implementarla en todos los casos afectados. El despliegue está progresando en función de la región por región y los servicios vuelven a la normalidad en las regiones donde se ha completado el despliegue.

3. 16 de septiembre de 2026 a las 19:25 UTCmonitoring

   Nuestro proveedor de servicios informa que la telemetría de servicio ha permanecido sana después del despliegue de la mitigación. La comunidad sigue siendo accesible en este momento, y no se ha identificado ningún impacto constante confirmado. Seguiremos vigilando el medio ambiente para garantizar la estabilidad permanente mientras se completen las actividades de validación final. Proporcionaremos otra actualización a medida que se disponga de información adicional.

4. 16 de septiembre de 2026 a las 22:00 UTCmonitoring

   Nuestro proveedor de servicios ha declarado el incidente subyacente resuelto después de la mitigación exitosa y la validación ampliada. La comunidad sigue siendo accesible, y no se ha determinado ningún impacto constante confirmado. La vigilancia durante todo el período de recuperación no ha determinado cuestiones adicionales. Este incidente se considera resuelto.

5. 17 de septiembre de 2026 a las 11:01 UTCresolved

   Nuestros equipos han seguido vigilando el servicio durante todo el período de recuperación y no se han observado problemas adicionales. Sobre la base de la estabilidad sostenida del servicio, este incidente se considera resuelto.

6. 30 de septiembre de 2026 a las 12:30 UTCpostmortem

   **Descripción:** Servicio comunitario de Flexera **Tiempo:** 16 de septiembre de 2026, 12:50 AM PDT al 16 de septiembre de 2026, 8:26 AM PDT ** Resumen del incidente** El 16 de septiembre de 2026, a las 12:50 AM PDT , Flexera identificó un problema que afecta a la disponibilidad y fiabilidad del sitio de la Comunidad Flexera debido a un outage que afecta a un proveedor externo de servicios que apoya la plataforma comunitaria. Durante el incidente, los clientes pueden haber sido incapaces de acceder a la Comunidad Flexera, plantear o gestionar casos de apoyo, o recibir respuestas a los casos existentes a través de la Comunidad. Los correos electrónicos enviados a [email protected] también pueden haberse retrasado o no procesado durante la salida. El problema también afectó la funcionalidad de chatbot dentro de la consola Spot, que se basa en los servicios impactados. Además, el outage afectó la capacidad de vigilancia proactiva utilizada por los equipos Spot Support para identificar ciertos problemas de entorno de clientes que dependen de las notificaciones de servicios. El proveedor de servicios validó posteriormente una solución y comenzó a desplegarla en todas las instancias afectadas sobre una base regional por región. A medida que se desplegó la mitigación, los servicios regresaron progresivamente a la normalidad. Tras el despliegue, la telemetría de servicio siguió siendo saludable en entornos orientados al cliente. La validación confirmó que la funcionalidad de Flexera Community y Spot chatbot funcionaban normalmente. The underlying provider incident was subsequently declared resolved, and Flexera completed final validation and closed the incident.. *Causa real* El incidente fue causado por un outage que afectó a los servicios de un proveedor externo de servicios que apoyan la Comunidad Flexera y funcionalidad relacionada. La perturbación del servicio afectó la disponibilidad y fiabilidad de la plataforma comunitaria y las integraciones asociadas, lo que dio lugar a una perturbación temporal de la funcionalidad de los casos de atención al cliente y las capacidades de Spot relacionadas. ** Acciones de rehabilitación** * Remediación del proveedor: El proveedor de servicios externo validó y desplegó una solución en los casos afectados. * Validación de servicios: Los equipos de Flexera supervisaron la Comunidad, la funcionalidad de chatbot y los servicios conexos cuando se desplegó la rehabilitación. * Supervisión de la recuperación: Se supervisaron la salud y la funcionalidad de los servicios para confirmar la estabilidad tras la rehabilitación. * Cierre de incidentes: Después de que se resolvió el problema del proveedor subyacente y se completó la validación de Flexera, el incidente se cerró. **Medidas preventivas completas** * Supervisión de la dependencia mejorada: Seguir monitoreando dependencias externas críticas que apoyen los servicios de atención al cliente. * Evaluación del impacto del cliente: Continuar evaluando el impacto de las interrupciones del servicio externo en los servicios integrados de Flexera, incluyendo Comunidad, gestión de casos de apoyo y funcionalidad Spot. * Monitorización post-incidente: Continuar monitoreando el impacto residual del cliente después de la restauración de servicios externos.

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

1. 15 de septiembre de 2026 a las 23:05 UTCinvestigating

   Descripción del incidente: Actualmente estamos investigando un problema que afecta a los servicios de Políticas y Automatización en el entorno de producción de la UE. Los clientes de la UE pueden experimentar fallos al utilizar Políticas y pueden ser incapaces de ver sus políticas a través de la interfaz de usuario. El impacto se limita a la región de la UE. Prioridad: P2 Actividad de Restauración: Nuestros equipos técnicos se han comprometido y están investigando activamente una cuestión encontrada durante una actualización de infraestructura para identificar la causa subyacente y restaurar el servicio normal lo antes posible. Se proporcionarán más actualizaciones a medida que avance la investigación.

2. 16 de septiembre de 2026 a las 6:16 UTCmonitoring

   Se ha resuelto la cuestión que afecta al entorno de la UE y se ha restablecido el acceso a la interfaz de usuario. Mientras el servicio está operando normalmente, puede tomar algún tiempo para el atraso del trabajo solicitado que se acumula durante el outage para ser procesado. Nuestros equipos están monitoreando activamente la recuperación para asegurar que el atraso se limpie y los servicios siguen funcionando según lo previsto. Seguiremos vigilando el medio ambiente de cerca y confirmaremos una vez que el procesamiento haya regresado completamente a los niveles normales.

3. 16 de septiembre de 2026 a las 8:24 UTCresolved

   Nuestros equipos han seguido vigilando de cerca el servicio y no se han observado nuevas cuestiones. El atraso del trabajo que se acumula durante la interrupción se está procesando con éxito y sigue disminuyendo según lo previsto. Sobre la base de la estabilidad observada desde la recuperación, este incidente se resuelve ahora. Seguiremos monitoreando el procesamiento para asegurar que el atraso se despeje completamente y el servicio siga funcionando según lo previsto.

4. 12 de octubre de 2026 a las 12:02 UTCpostmortem

   **Descripción:** Flexera - UE - Políticas/Automación No disponible **Tiempo:** 15 de septiembre de 2026, 3:50 PM PDT al 16 de septiembre de 2026, 1:22 AM PDT ** Resumen del incidente** El 15 de septiembre de 2026, a las 3:50 PM PDT, una actualización de infraestructura que apoya la automatización en el entorno de producción de la UE dio lugar a una perturbación de conectividad de red que afecta a las políticas y la automatización. Los clientes experimentaron dificultades para ver las políticas en la interfaz de usuario, y las operaciones relacionadas con las políticas fracasaron. La investigación identificó comportamiento inesperado de un componente de red legado . Esta conectividad interrumpida requerida por los servicios afectados. El equipo identificó el componente involucrado y trajo el recurso necesario en línea, restaurando la conectividad de red. La cuestión subyacente se resolvió el 15 de septiembre a las 10:13 PM PDT. A continuación, el equipo continuó la recuperación de los servicios de vigilancia y el procesamiento del atraso acumulado durante la interrupción. Una vez que el procesamiento atrasado había progresado según se esperaba y se confirmó la estabilidad de servicio, el incidente fue declarado totalmente restaurado el 16 de septiembre de 2026, a las 1:22 AM PDT. El impacto se limitó al entorno de producción de la UE. *Causa real* El incidente fue causado por comportamientos inesperados de un componente de red legado durante la mejora de la infraestructura de automatización en la región de la UE. Esto interrumpió la conectividad de red requerida por Políticas y Automatización, lo que dio lugar a la falta de disponibilidad de servicios y a fallas en la funcionalidad relacionada con las políticas. ** Acciones de rehabilitación** Nuestros equipos realizaron las siguientes acciones para restaurar los servicios a la normalidad: * Restauración de conectividad: identificó el componente legado involucrado y trajo el recurso requerido en línea para restaurar la conectividad de red. * Recuperación de servicios: Conectividad restaurada y resolvió el problema subyacente que afecta a Políticas y Automatización. * Tratamiento de Backlog: Supervisó el atraso acumulado como procesamiento recuperado después de la restauración del servicio. * Validación posterior a la restauración: Confirmación de la estabilidad del servicio y verificación de que el procesamiento atrasado estaba progresando como se esperaba antes de declarar el incidente totalmente restaurado. **Medidas preventivas completas** * Planificación migratoria: La migración correspondiente a los Estados Unidos fue reestructurada con una ventana de mantenimiento más larga para permitir tiempo adicional para la solución de problemas y la recuperación. * Reemplazo del componente Legacy: El componente legado se está reemplazando como parte del esfuerzo de modernización de la infraestructura. Una vez que el reemplazo esté completo, se espera que esta dependencia heredada específica sea eliminada en todos los entornos.

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

1. 14 de septiembre de 2026 a las 22:23 UTCinvestigating

   Descripción del incidente: Actualmente estamos investigando un problema que afecta el acceso a los servicios de Flexera One en la región del NAM. Los clientes afectados pueden experimentar dificultades para acceder a la plataforma o pueden encontrar errores después de la autenticación. Prioridad: P1 Actividad de Restauración: Nuestros técnicos se han comprometido y están investigando activamente la cuestión para identificar la causa subyacente y restaurar el servicio normal lo antes posible.

2. 14 de septiembre de 2026 a las 23:00 UTCresolved

   Nuestra investigación identificó un problema de conectividad dentro de un camino de dependencia de servicios que afectó el acceso de los clientes en el entorno de América del Norte. Nuestros equipos técnicos actualizaron la configuración de enrutamiento, restaurando con éxito la conectividad entre los servicios afectados. El servicio ha sido totalmente restaurado y funciona normalmente. La cuestión se resuelve.

3. 12 de octubre de 2026 a las 10:47 UTCpostmortem

   **Descripción:** Flexera One - NAM - Access Disruption **Tiempo:** 14 de septiembre de 2026, 2:39 PM PDT al 14 de septiembre de 2026, 3:42 PM PDT ** Resumen del incidente** El lunes 14 de septiembre de 2026, a las 2:39 PM PDT, nuestros equipos identificaron un problema que afectaba el acceso al cliente a Flexera One en la región de producción de América del Norte. Los síntomas incluyeron fallos prolongados de carga de aplicaciones y autenticación. The investigation confirmed that the impact was limited to NAM. The investigation identified a connectivity issue between services responsible for access control and audit-related function. Following a planned change, requests were directed to a downstream service environment that could not be reached through the established communication path. Esto interrumpió la comunicación entre los servicios dependientes, lo que dio lugar a repetidos fallos de servicio e inestabilidad que afectaron el acceso de los clientes. Los equipos técnicos corrigieron la configuración de enrutamiento afectada y la conectividad restaurada entre los servicios dependientes. Tras estos cambios, se recuperó la estabilidad de servicio y se validó el acceso de los clientes a Flexera One en NAM. El incidente fue resuelto el 14 de septiembre de 2026, a las 3:42 PM PDT, y la plataforma volvió a la operación normal. *Causa real* The incident was caused by an incorrect service routing settings introduced during the migration of audit-related services in the NAM environment. Esto impidió que los servicios dependientes se comunicaran con éxito, lo que dio lugar a la inestabilidad de los servicios y a los fallos de acceso de los clientes. Factor de contribución: The traffic migration to Audit Services in the NAM region proceeded without fully establishing service connectivity and preparedness in the target environment. Aunque la migración correspondiente funcionaba con éxito en otras regiones de producción, se requería una validación adicional antes de proceder con el MNO. ** Acciones de rehabilitación** Los equipos técnicos de Flexera realizaron las siguientes acciones para restaurar los servicios a la normalidad: * Corrección de enrutamiento: Actualización de la configuración de enrutamiento de servicios afectados para restaurar la conectividad entre los servicios dependientes. * Recuperación de servicios: Confirmó que los servicios afectados recuperaron y regresaron a una operación estable. * Validación de acceso: Acceso al cliente con éxito validado a Flexera One en la región de producción de NAM. * Vigilancia posterior a la restauración: salud de servicio verificada después de la rehabilitación para confirmar que se había reanudado la operación normal. **Medidas preventivas completas** * validación previa a la migración: Fortalecer la validación de los servicios dependientes para asegurar que sean accesibles y funcionen correctamente en la región de destino antes de migrar el tráfico de producción. * Comprobaciones regionales de preparación: Fortalecer las evaluaciones de la preparación para cada región. * Salvaguardias migratorias: Introducir puntos de control de validación adicionales para identificar problemas de conectividad y enrutamiento antes de afectar a los clientes. * Verificación posterior a la migración: Realizar controles de conectividad de servicios específicos y acceso al cliente después de cada migración de tráfico regional.

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