Historial de interrupciones de Loom

1. 8 de mayo de 2026 a las 3:00 UTCinvestigating

   Estamos experimentando problemas con múltiples productos Atlassianos. Nuestros equipos están investigando más y más actualizaciones, incluyendo serán compartidos dentro de 1 hora.

2. 8 de mayo de 2026 a las 4:10 UTCidentified

   Hemos identificado que la causa raíz del problema está relacionada con un gasto de infraestructura de nuestro proveedor de nube pública. Trabajamos estrechamente con ellos para mitigar esta cuestión. Proporcionaremos más actualizaciones cuando estén disponibles.

3. 8 de mayo de 2026 a las 4:10 UTCidentified

   Nuestros equipos continúan trabajando en la mitigación de la pérdida de infraestructura de nuestro proveedor de nube pública. Proporcionaremos más actualizaciones cuando estén disponibles.

4. 8 de mayo de 2026 a las 4:10 UTCidentified

   Continuamos trabajando con nuestro proveedor de nube pública para mitigar este problema. Estamos empezando a ver alguna recuperación en regiones fuera de los EE.UU. Oriental, sin embargo, los usuarios de todo el mundo todavía pueden estar experimentando problemas con ciertas características del producto. Estos se enumeran en la parte inferior de cada página de producto.

5. 8 de mayo de 2026 a las 5:53 UTCmonitoring

   Se ha mitigado la cuestión subyacente de la infraestructura pública que afectó el procesamiento de eventos asincrónicos y se están recuperando todos los servicios afectados. Ahora estamos trabajando en la limpieza del atraso de los eventos apagados, lo que significa que algunas acciones (como notificaciones, disparadores de automatización y sincronizaciones de datos) pueden estar en estado degradado. Seguiremos monitoreando y proporcionando actualizaciones ya que el atraso está aclarado.

6. 8 de mayo de 2026 a las 8:03 UTCmonitoring

   Seguimos vigilando la situación a medida que se recuperan los servicios. Actualmente estamos en proceso de despejar el atraso de los eventos apagados. Proporcionaremos una actualización adicional en aproximadamente una hora.

7. 8 de mayo de 2026 a las 11:12 UTCmonitoring

   Nuestros servicios están ahora plenamente operativos. Seguimos reproduciendo cualquier evento que se perdió durante el incidente, y estamos haciendo un buen progreso. Proporcionaremos otra actualización una vez que las repeticiones estén completas. Si experimenta algún problema en curso, por favor contacte con nuestro equipo de soporte. Nos disculpamos por la interrupción y le agradecemos por su paciencia.

8. 8 de mayo de 2026 a las 19:45 UTCresolved

   El 8 de mayo de 2026, algunos clientes que utilizan productos Atlassianos experimentaron altas tasas de error y rendimiento degradado. El problema se ha resuelto y el servicio funciona normalmente para todos los clientes afectados.

9. 20 de mayo de 2026 a las 6:57 UTCpostmortem

   Todas las fechas y fechas a continuación están en UTC a menos que se indique lo contrario. #### Summary El 8 de mayo de 2026 entre las 00:22 y las 06:08, uno de nuestros proveedores de hospedaje sufrió un incidente significativo en una zona de disponibilidad específica en prod-east que llevó a clientes de Atlassian experimentar rendimiento degradado y retrasos de operaciones de fondo y ejecución de automatización. El incidente comenzó el 8 de mayo de 2026 a las 00:22 y fue detectado dentro de 4 minutos por sistemas de monitoreo automatizados. Nuestros equipos trabajaron para restaurar el acceso básico para las 06:08. La limpieza final de los procesos respaldados y las cuestiones menores progresaron en etapas desde allí se completó iterativamente en 19:15. #### **IMPACT** La infraestructura principal afectada en este incidente fue el gasoducto de procesamiento de eventos en la región prod-este, que distribuye eventos entre servicios Atlassianos y apoya operaciones de fondo como la ejecución de automatización, indexación de búsqueda, notificaciones, sincronización de permisos. * Entre las 00:22 y las 06:08, un incidente de infraestructura en nuestro proveedor de alojamiento provocó un fallo de ingestión en nuestra tubería de procesamiento de eventos. * At 02:50, event ingestion was failed over to an un affected availability zone, progressively restorering live event flows. * A las 06:08, confiabilidad para la nueva ingestión en prod-east recuperada al 100%. El trabajo restante era drenar el atraso acumulado de la lista cruzada de mensajes, que terminó a las 17:00. * Para 18:48, Automation había procesado su acumulación de eventos que se crearon durante el procesamiento **Automatización* Entre las 00:22 y las 02:50, los clientes con reglas de automatización activadas por eventos originarios de la región prod-este experimentaron una reducción significativa en las ejecuciones de reglas. Durante esta ventana, las reglas de automatización desencadenadas por eventos no estaban disparando porque los eventos que los desencadenaban no estaban siendo entregados. Autorización de reglas, ahorro y reglas activadas manualmente, por horarios, o por webhooks no se vieron afectados. A las 02:50, la infraestructura de procesamiento de eventos falló en una zona de disponibilidad no afectada, restaurando la entrega de eventos en vivo a Automation y permitiendo nuevas reglas desencadenadas por eventos para comenzar a ejecutar normalmente. Sin embargo, los acontecimientos generados durante la ventana de impacto todavía necesitan ser reproducidos antes de que se puedan procesar las automatización retrasadas. A partir de las 08:28, los servicios de corriente rejuvenecieron sus eventos en una secuencia coordinada, y todos los eventos reinterpretados fueron procesados por 18:48. Durante la ventana de reproducción, los clientes pueden haber experimentado reglas de automatización ejecutando más adelante de lo esperado, un pequeño número de reglas que alcanzan los límites de procesamiento diarios debido a la repetición comprimida, y reglas sensibles al tiempo que no se completan como se esperaba si se superaran los umbrales de tiempo interno. **Jira y Jira Service Management** Entre las 00:22 y las 02:50, los clientes con inquilinos alojados en la región prod-este experimentaron trastornos a Jira y Jira Service Management características impulsadas por eventos como la automatización, junto con un corto período de errores elevados durante la falla de infraestructura. Durante todo el incidente se mantuvieron disponibles las experiencias de Core Jira, incluidas las opiniones sobre cuestiones, las juntas y la navegación de proyectos. La entrega de eventos de Jira se vio afectada por el impacto primario, evitando que los servicios de abajo reciban eventos de ciclo de vida de emisión. Estas reglas de automatización afectadas desencadenadas por eventos Jira, orquestación de agentes AI en Jira, notificaciones de actualizaciones de emisión y transiciones, indexación de búsqueda de problemas nuevos creados o modificados, e integraciones impulsadas por eventos entre Jira y otros productos Atlassianos. A las 02:50, la infraestructura de procesamiento de eventos falló en una zona de disponibilidad no afectada, restaurando la entrega de nuevos eventos. Todos los eventos generados durante la ventana de impacto fueron retenidos en una cola de recuperación y repetidas. Esto comenzó a las 08:28 y terminó a las 12:00. Durante la ventana de reproducción, los clientes pueden haber experimentado reglas de automatización ejecutando más adelante de lo esperado, notificaciones demoradas que llegan horas después de la acción de activación, lagunas temporales en los resultados de búsqueda de contenido creados o modificados durante la ventana de impacto, y flujos de trabajo de agentes de IA que no se completan como se esperaba cuando los umbrales de tiempo interno fueron superados. *Confluencia* Entre las 00:22 y las 02:50, los clientes con inquilinos alojados en la región prod-east experimentaron perturbaciones a servicios impulsados por eventos en Confluence. Esto dio lugar a demoras en la indexación de búsqueda, notificaciones, ejecución de reglas de automatización y sincronización de permisos. La infraestructura de procesamiento de eventos subyacentes no afectó a una zona de disponibilidad no afectada, después de la cual las operaciones de Confluencia en vivo reanudaron normalmente. Sin embargo, los acontecimientos generados durante la ventana de impacto fueron consultados para reproducirse, y algunos servicios de antecedentes se mantuvieron retrasados hasta que concluyera esa labor de reproducción y validación conexas. Entre las 10:14 y las 17:00, se completó una repetición a granel de todas las tareas de reproducción de inquilinos apagados para restaurar la consistencia de los datos. Durante e inmediatamente después de la ventana de reproducción, los clientes pueden haber experimentado resultados de búsqueda que no reflejen el contenido creado o modificado durante el outage, notificaciones demoradas o faltantes para la actividad de página y comentario, reglas de automatización disparando más tarde de lo esperado, y breves demoras en la sincronización de permisos para los inquilinos que dependen de la sincronización de identidad incremental. #Bitbucket and Pipelines # Entre las 00:22 y las 06:08, los clientes que utilizan Bitbucket y Pipelines experimentaron fallos y degradaron la funcionalidad en los flujos de trabajo impulsados por eventos. Las operaciones de Core Git, incluyendo empuje, tira y clon, no se vieron afectadas y continuaron operando normalmente durante todo el incidente. Los disparadores automáticos de oleoducto iniciados por los eventos de solicitud de empuje o tirado no estaban disponibles durante la ventana de impacto. Combinar colas, controles de fusión personalizadas, desencadenantes basados en forja, cambios de permiso del espacio de trabajo, y algunos flujos de suministro del espacio de trabajo también fueron afectados. Los clientes que utilizan colas de fusión no pudieron fusionar solicitudes de tiraje, y algunos pasos de oleoducto fallaron porque el trabajo solicitado contribuyó a elevar los límites de concurrencia. Aproximadamente a las 03:57, Pipelines fue reconfigurado para consumir eventos a través de un camino alternativo, restaurando el disparador automático de tuberías. Las colas de fusión, los controles de fusión personalizados, los desencadenantes de Forge y otros flujos de trabajo afectados fueron restaurados progresivamente a medida que se recuperaba la infraestructura de procesamiento de eventos subyacentes. Todos los servicios de Bitbucket y Pipelines fueron confirmados totalmente operativos por 06:08. Después de la recuperación, se revisaron y reinterpretaron los acontecimientos en los que se pudo recuperar la coherencia de los datos para facturar, registrar auditorías y otros procesos de antecedentes. ** Servicios de identidad** Entre las 00:22 y las 02:50, los clientes con inquilinos alojados en la región prod-east experimentaron retrasos en la propagación de la identidad y los cambios de membresía de grupo a los productos de Atlas. Las operaciones básicas de identidad, incluidas las acciones de autenticación, login y gestión directa de grupos, no se vieron afectadas y continuaron funcionando normalmente durante todo el incidente. El impacto se limitó a operaciones asincrónicas impulsadas por eventos que dependen de la tubería de procesamiento de eventos. Esto incluyó retrasos en la entrega de miembros de grupo y cambios de perfil de usuario a productos como Jira y Confluence, que afectaron la sincronización de permisos aguas abajo y flujos de sincronización de multitudes. Un pequeño número de flujos de trabajo de sincronización de identidad basados en SCIM y suministro de sitios también experimentó demoras temporales. Después de la recuperación de la infraestructura de procesamiento de eventos, se reiniciaron eventos de identidad y directorios de grupo cuando fuera necesario, restaurando la consistencia de aguas abajo para los productos afectados. No se perdieron datos de identidad. Tras la recuperación, se retuvieron y procesaron los cambios en la composición del grupo, las actualizaciones del perfil de usuario y los acontecimientos relacionados con la provisión que ocurrieron durante la ventana de impacto. ### ** Acciones urgentes PLAN & NEXT STEPS** Sabemos que las interrupciones impactan su productividad. Si bien nuestros procesos de vigilancia y recuperación nos ayudaron a responder rápidamente, este incidente puso de relieve oportunidades para fortalecer aún más la resiliencia de los servicios impulsados por los eventos. Estamos priorizando mejoras que: * ** Mejorar la cobertura de failover** para que el procesamiento de eventos crítico pueda recuperarse con más facilidad durante las perturbaciones de infraestructura. * **Manejo de recuperación de Strengthen** para que los eventos repetidos puedan ser procesados más rápido. Nos disculpamos con clientes cuyos servicios fueron impactados durante este incidente; estamos tomando medidas inmediatas para mejorar el rendimiento y la disponibilidad de la plataforma. Gracias. Atención al cliente de Atlassian.

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

1. 29 de abril de 2026 a las 7:00 UTCinvestigating

   We are investigating degraded performance issues affecting Loom's core functionalities - authentication, recording, viewing and editing looms. We will provide more details within the next hour.

2. 29 de abril de 2026 a las 7:50 UTCresolved

   The Team has identified the root cause and the issue has now been resolved, and the impacted services are operating normally. Team will continue to monitor the impacted services.

1. 3 de febrero de 2026 a las 10:24 UTCinvestigating

   Customers utilizing Confluence and Jira Mobile may experience disruptions in OAuth authentication flows. Forge installations and invocations might also be disrupted. Our team is actively investigating the same and we shall keep you informed of the progress within next 60 mins or sooner.

2. 3 de febrero de 2026 a las 10:50 UTCresolved

   Team has identified the root cause and the issue has now been resolved, and the impacted services are operating normally. Team will continue to monitor the impacted services.

1. 19 de noviembre de 2025 a las 22:32 UTCidentified

   We are aware of some customers that are experiencing no audio when viewing their Loom recordings. Our team has identified this issue and is working urgently to restore the audio for these recordings. Please rest assured that the audio has been recorded correctly, and we expect this to be fully available when this incident is resolved. New recordings are no longer impacted by this issue. We will provide an update within two hours with our progress as the team continues to investigate.

2. 20 de noviembre de 2025 a las 0:33 UTCidentified

   Our team believes that we have identified the cause of the issue impacting audio during playback of videos for some customers. As mentioned in our previous updates, new recordings will be working as expected, however videos recorded between 19 Nov 16:51 UTC and 19 Nov 21:30 UTC are expected to be impacted by this issue. A fix for this issue to restore audio to these recordings is now being developed and tested, and we expect to have further update within 2 hours on progress for this resolution.

3. 20 de noviembre de 2025 a las 2:30 UTCidentified

   The fix to resolve issues on audio recordings impacted by this incident is now being prepared for deployment. Currently the expected duration of the rollout is 3 hours, at which point we expect the audio from the impacted recordings to be fully restored. We will provide further update at that time with the progress of the restoration and provide any additional information that may be required.

4. 20 de noviembre de 2025 a las 5:39 UTCresolved

   The rollout of the fix for impacted videos without audio has now completed. Customers should now be able to review existing videos without audio and see that it has been properly restored. If you are continuing to see any issues with playback of your videos, please reach out to Loom support for assistance. We apologize for any inconvenience caused by this issue.

1. 27 de octubre de 2025 a las 15:35 UTCinvestigating

   Estamos investigando un problema con Recording, Loom AI, Authentication y billing que está impactando a algunos clientes de Loom Cloud. Proporcionaremos más detalles en la próxima hora.

2. 27 de octubre de 2025 a las 16:33 UTCinvestigating

   Continuamos investigando el tema con Recording, Loom AI, Authentication y Billing que está impactando a algunos clientes de Loom Cloud. Estamos investigando y publicaremos actualizaciones a las 17:35 UTC o antes.

3. 27 de octubre de 2025 a las 17:34 UTCinvestigating

   Continuamos investigando el tema con Recording, Loom AI, Authentication y Billing que está impactando a algunos clientes de Loom Cloud. Publicaremos otra actualización a las 18:35 UTC o antes, ya que las cosas progresan.

4. 27 de octubre de 2025 a las 18:32 UTCinvestigating

   Continuamos investigando activamente el tema con Recording, Loom AI, Authentication y billing que está afectando a algunos clientes de Loom Cloud. Apreciamos su paciencia. Publicaremos otra actualización a las 19:35 UTC o antes, ya que las cosas progresan.

5. 27 de octubre de 2025 a las 19:06 UTCmonitoring

   Hemos identificado la causa raíz del problema con Recording, Loom AI, Authentication y billing que está impactando a algunos clientes de Loom Cloud. Hemos aplicado medidas de mitigación para abordar el problema y ahora estamos monitoreando de cerca. Proporcionaremos otra actualización a las 20:00 UTC o antes, ya que las cosas progresan.

6. 27 de octubre de 2025 a las 19:59 UTCmonitoring

   Estamos implementando activamente nuevas mitigacións para resolver el problema que afecta a Recording, Loom AI, Authentication, y facturación para algunos clientes de Loom Cloud. Seguiremos monitoreando de cerca y proporcionaremos otra actualización a las 21:00 UTC o antes, ya que las cosas progresan.

7. 27 de octubre de 2025 a las 21:06 UTCmonitoring

   Hemos implementado nuevas mitigacións para resolver el problema que afecta a Recording, Loom AI, Authentication y facturación para algunos clientes de Loom Cloud. Estamos viendo buenos signos de recuperación y todos los servicios están operativos. Seguiremos monitoreando de cerca y proporcionaremos otra actualización a las 22:00 UTC o antes, ya que las cosas progresan.

8. 27 de octubre de 2025 a las 22:00 UTCresolved

   El 27 de octubre de 2025, entre las 12:30 y las 22:15 UTC, experimentamos un rendimiento degradado que afecta a los servicios de Grabación, Loom AI, Autenticación y Facturación para algunos clientes de Loom. Hemos implementado una solución para mitigar la cuestión y hemos comprobado que los servicios se han recuperado. Las condiciones que causan el problema se han abordado y estamos trabajando activamente en una solución permanente. La cuestión se ha resuelto y el servicio funciona normalmente. Una vez que completemos nuestro proceso de revisión de incidentes internos, publicaremos un postmortem más detallado de lo que salió mal, junto con los pasos que estamos tomando para evitar que esto suceda de nuevo en el futuro. Nota: Como resultado de este incidente, algunos Looms registrados durante el período de rendimiento degradado pueden haber permanecido en un estado de carga. Estos videos no son recuperables, y han sido archivados de las bibliotecas de los usuarios.

9. 21 de noviembre de 2025 a las 19:49 UTCpostmortem

   #### Summary El 27 de octubre de 2025 entre las 12:30 y 20:55 UTC, Loom fue degradado significativamente para todos los clientes. Los usuarios también experimentaron breves períodos de degradación el 28 de octubre de 20:26 a 20:33 UTC y 30 de octubre de 2025 19:22 a 19:27 UTC. Durante el incidente, los usuarios experimentaron problemas con reproducción intermitente o fallante, grabaciones, generación de transcripciones, problemas de registro, y errores generales o lentitud en todo el servicio. Nuestro monitoreo muestra que entre el 20% y el 80% de las interacciones de los usuarios estaban fallando durante estos períodos, con fallos creciendo en la mitad posterior del incidente. Sabemos que los outages impactan su productividad y nos disculpamos a los clientes que fueron afectados durante este incidente. Estamos tomando medidas inmediatas para mejorar la fiabilidad de Loom basado en nuestros aprendizajes de este incidente. ### Analysis A partir del 25 de octubre de 2025, el grupo principal de base de datos de Loom mostró indicadores tempranos de un problema. El uso de los recursos estaba creciendo lentamente y las ranuras de reproducción no se mantenían. Los ingenieros fueron alertados el 26 de octubre de 2025 y comenzaron a investigar. No vimos señales de impacto del cliente en este momento, sin embargo, identificamos un problema con un trabajo de fondo retrigante funcionando sin éxito en un bucle. Enviamos una solución temporal para este problema y planeamos investigar más al día siguiente. El lunes 27 de octubre de 2025, la cuestión se resuperó significativamente a medida que el uso aumentó, y empezamos a observar el impacto del cliente. Los ingenieros vigilan de cerca la cuestión y se dedican de inmediato. Estaba claro que nuestra base de datos no estaba funcionando como se esperaba, y durante las próximas horas, hicimos múltiples intentos de mitigación. Notablemente, escalamos el escritor de bases de datos y dos lectores para aliviar la presión de recursos. Esto no ayudó, y el impacto del usuario siguió sin cambios. Durante las próximas horas, hicimos múltiples intentos de restaurar el rendimiento normal de la base de datos. Enrollamos cambios recientes, optimizamos el rendimiento de las consultas individuales, añadimos nuevos índices, configuraciones de bases de datos actualizadas, y aspiramos grandes tablas de sistemas y aplicaciones. Estos cambios proporcionaron algún alivio a corto plazo, pero el rendimiento aumentó repetidamente. Dejar nuestras ranuras de reproducción resolvió la presión de los recursos, pero no mejoró el rendimiento general de las consultas. Luego observamos que las consultas idénticas estaban planeando y ejecutando mucho más rápido en el escritor que en nuestros casos de lectores, así que decidimos cambiar todo el tráfico de consultas a la única instancia de escritor. Este cambio mitigó inmediatamente el impacto del cliente. Si bien esta acción resolvió la cuestión inmediata, no fue un estado estable para nuestro servicio a largo plazo. Durante los próximos días, hicimos múltiples intentos de volver a nuestra arquitectura típica de un solo escritor y de doble lectura. Cada vez, vimos las mismas cuestiones resurgir, dando lugar a períodos cortos de degradación. Entre cada uno de estos intentos, hicimos nuevas optimizaciones al uso de nuestra base de datos, pero todavía no estábamos viendo el rendimiento que esperábamos al agregar de nuevo nuestros casos de lectores. Esto fue especialmente difícil porque nuestros servicios funcionaban como se esperaba con un solo lector, y sólo observamos esta degradación al agregar un segundo lector al grupo. El 31 de octubre de 2025, probamos la falla con un tamaño de instancia más pequeño, similar a nuestra arquitectura original antes del intento de escalado vertical. Esto sucedió, restaurando la arquitectura del Loom a la normalidad y atenuando completamente el incidente. ## Root Cause En términos generales, este incidente puede dividirse en dos partes. En primer lugar, la degradación inicial fue causada por múltiples cambios de Loom realizados en los meses anteriores al incidente. En segundo lugar, la mitigación ampliada se debió inesperadamente a nuestro intento de mitigar el aumento del tamaño de las instancias. La primera parte de este incidente fue causada por una compleja interacción de múltiples cambios antiguos y recientes en los servicios de Loom: * Durante años, Loom ha tenido un trabajo de fondo que utiliza transacciones de bases de datos anidadas, un patrón raro en nuestra base de código. Se abre una transacción parental para todo el trabajo, con transacciones infantiles para cada lote de trabajo. Este trabajo ha sido confiable, pero volverá a intentar varias veces en caso de fracaso. Este trabajo es relativamente bajo y generalmente rápido, pero puede requerir un trabajo significativo de base de datos en casos raros. * En los últimos meses, para apoyar las próximas características y migraciones, la carga de referencia y la actividad en la base de datos de Loom aumentaron significativamente. * El 14 de octubre de 2025, también para apoyar una función próxima, se hizo un amplio cambio en cómo la aplicación Loom maneja las transacciones de base de datos. Este cambio sólo estaba destinado a entrar en vigor en nuestros entornos de prueba y puesta en escena, pero en casos especiales relacionados con transacciones anidadas, también se aplicaba en la producción. * El 25 de octubre de 2025, los cambios combinados desencadenaron una degradación lenta y creciente de nuestra base de datos. Varios trabajos de fondo grandes se combinan y fracasan, causando que los registros mantengan una transacción abierta permanente en la base de datos. Esta reproducción degradada ranuras y autovacuo, que conduce a la hinchazón de mesa en toda la base de datos. El 27 de octubre de 2025, esta degradación comenzó a afectar a nuestros usuarios. * Después de eliminar los desencadenantes iniciales, la base de datos siguió degradando y requería una intervención manual significativa para estabilizarse. La recuperación fue complicada porque un intento de mitigación \(por ejemplo vertical escalar\) desencadena un nuevo problema. La segunda parte de este incidente fue causada por nuestro anterior intento de mitigación de escalar nuestros tamaños de instancia para manejar el aumento de la carga de la primera parte: * A principios del incidente, en respuesta al aumento del uso de los recursos de base de datos, intentamos mitigar escalando verticalmente nuestras instancias a tamaños más grandes. Generalmente consideramos que esto es una mitigación segura y a menudo eficaz. * Este cambio inesperadamente hizo empeorar la degradación de la base de datos. El tipo de degradación que observamos de los casos más grandes fue similar al tipo de degradación que ya observamos en la primera parte del incidente. Después del incidente aprendimos directamente de nuestro proveedor de nube que los tamaños de instancia más grandes utilizan una arquitectura de memoria separada que realiza significativamente peor en nuestra carga de trabajo. * Esta diferencia de rendimiento entre los tipos de instancia es especialmente evidente al abrir nuevas conexiones. Como parte de nuestra investigación, también encontramos un problema con nuestro pooler de conexión que conduce al exceso de conexión churn al señalar un punto final de lector balanceado por carga DNS. Esto explica por qué sólo observamos problemas al agregar un segundo lector al clúster, y no con una configuración de un solo escritor. ### **Remediaciones y mejoras** Como parte de nuestros esfuerzos de investigación y mitigación durante el incidente, ya hemos completado varias medidas clave para abordar cuestiones similares, entre ellas: * Optimizado manejo de transacciones dentro de nuestra aplicación. * Mejor rendimiento de las consultas de alto volumen y de bajo rendimiento. * Mejora de la vigilancia y la observabilidad del estado de vacío y la hinchazón de mesa. * Mejoras internas de herramientas para facilitar la depuración * banner de producto para alertar a los usuarios durante incidentes. Además, estamos priorizando las siguientes acciones de mejora: * Mejoras adicionales en la gestión y vigilancia de las transacciones. * Optimización de nuestra configuración de conexión. * Optimizaciones de uso del índice de base de datos. * Mejoras de configuración de bases de datos. * Mejoras a los parámetros de autovacuo. * Mejoras en cómo midemos y monitorizamos el impacto del cliente. Gracias. Atlassian

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

1. 20 de octubre de 2025 a las 7:56 UTCinvestigating

   We have noticed that Atlassian Cloud services are impacted and our teams are actively investigating the same. We shall keep you informed of the progress every hour.

2. 20 de octubre de 2025 a las 8:24 UTCinvestigating

   Atlassian Cloud services are impacted and we are aware that our customers might not be able to create support tickets. Our teams are actively investigating the same. We shall keep you informed of the progress every hour.

3. 20 de octubre de 2025 a las 9:24 UTCinvestigating

   We are experiencing an outage due to some issue at the end of our public cloud provider. We are working closely with them to get this resolved or mitigated as quickly as possible. ETA of the same is not know at the moment. We shall continue to share updates every hour, if not sooner.

4. 20 de octubre de 2025 a las 9:58 UTCidentified

   We understand that our public cloud provider has identified the cause of the issue. We are starting to see some recovery and is working towards mitigation. We appreciate your patience. We shall continue to share updates every hour, if not sooner.

5. 20 de octubre de 2025 a las 11:07 UTCidentified

   We continue to work with our public cloud provider towards mitigating the issue at the earliest. We appreciate your patience. We shall continue to share updates every hour, if not sooner.

6. 20 de octubre de 2025 a las 12:06 UTCidentified

   Atlassian team is actively engaged and continues to work with our public cloud provider to mitigate this issue at the earliest. We are starting to see partial operations succeed. We appreciate your patience. We shall continue to share updates every hour, if not sooner.

7. 20 de octubre de 2025 a las 13:58 UTCidentified

   Our public cloud provider is working to mitigate this issue quickly. We are seeing some early positive indicators and are continuing to monitor. We appreciate your patience and will continue to provide updates every hour or sooner.

8. 20 de octubre de 2025 a las 14:03 UTCidentified

   We understand your pain and mitigating or fixing this issue is of utmost importance. Our public cloud provider is actively working to mitigate this issue on priority. We have been seeing partial operational success. We appreciate your patience and will continue to provide updates every hour or sooner.

9. 20 de octubre de 2025 a las 16:36 UTCidentified

   Update - Thank you for your continued patience. We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority. Our public cloud provider is still actively working to mitigate this issue with urgency and while we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation. We will be providing hourly updates on this issue.

10. 20 de octubre de 2025 a las 17:27 UTCidentified

    Update - We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority. Our public cloud provider is actively working to mitigate this issue with urgency. While we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation. We will continue to provide updates every hour or sooner as new information becomes available.

11. 20 de octubre de 2025 a las 17:43 UTCidentified

    We are currently aware of an ongoing incident impacting Atlassian Cloud services due to an outage with our public cloud provider, AWS. We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority and we are closely monitoring the health of AWS services. While we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation. We will continue to provide updates every hour or sooner as new information becomes available.

12. 20 de octubre de 2025 a las 18:38 UTCmonitoring

    There have been no changes since our last update. We will provide our next updated by 9:00PM UTC or sooner as new information becomes available. We are currently aware of an ongoing incident impacting Atlassian Cloud services due to an outage with our public cloud provider, AWS. We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority and we are closely monitoring the health of AWS services. While we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation.

13. 20 de octubre de 2025 a las 21:26 UTCmonitoring

    Monitoring - We've started seeing continued product experience improvement. While we still have a backlog of event processing, we are seeing improvements in systems operational capabilities across all products. We estimate a significant improvement with the next few hours and will continue to monitor the health of AWS services and the effects on Atlassian customers. We appreciate your continued patience and remain committed to full resolution as we work through this situation. We will post our next update in two hours.

14. 20 de octubre de 2025 a las 22:58 UTCmonitoring

    Our teams are continuing to monitor the recovery of systems across Atlassian products. This update is to inform that the Atlassian Support portal is fully operational at this time for customers that wish to contact support.

15. 21 de octubre de 2025 a las 0:03 UTCmonitoring

    Our team is now seeing recovery across all impacted Atlassian products. We are continuing to monitor for individual products that may still be processing backlogged items now that services are restored. The Atlassian Support portal is currently still displaying a message directing customers to our temporary support channel. Please note that our support portal is currently fully functional for those attempting to raise requests. We are continuing to look into this alert to remove this message. We will provide further update on our recovery status in one hour.

16. 21 de octubre de 2025 a las 1:07 UTCmonitoring

    We continue to see recovery progressing across all impacted products as backlogged items continue to be processed. The Atlassian Support portal is currently displaying a message directing customers to our temporary support channel. Please note that our support portal is currently fully functional for those attempting to raise requests. We are continuing to look into this alert to remove this message. We will provide further update on our recovery status in two hours.

17. 21 de octubre de 2025 a las 3:24 UTCmonitoring

    The issue relating to the Atlassian Support portal displaying a message to customers to use our temporary support channel has now been resolved. The Atlassian Support portal is fully functional for any ongoing support issues. With regards to other Atlassian products, we continue to see recovery continuing across all impacted products and our teams are continuing to monitor as the recovery continues. We will provide further update on our recovery status within two hours.

18. 21 de octubre de 2025 a las 5:24 UTCresolved

    Our team is now able to see full recovery across the vast majority of Atlassian products. We are aware of some ongoing issues with specific components such as migrations and JSM virtual service agents, and our team is continuing to investigate with urgency. We apologise for the inconvenience that this incident has caused and we will provide further information when the Post Incident Investigation has been completed.

19. 24 de octubre de 2025 a las 17:53 UTCpostmortem

    ### Postmortem publish date: Nov 19th, 2025 ### Summary All dates and times below are in UTC unless stated otherwise. Customers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region. The incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025. We recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust. ### IMPACT Before examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies. Products such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1. While in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes. However, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It’s important to note that all in-scope application data for supported products is pinned according to a customer’s chosen region. **Jira** Between Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \(NLB\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions. Between Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval. Normally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers. Between Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide. **Jira Service Management \(JSM\)** JSM was impacted similarly to Jira above, with the same timeframes and for the same reasons. Between Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts. **Confluence** Between Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively. Though the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes. To protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored. **Automation** Between Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution. During this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage. By Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage. Between Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner. **Bitbucket and Pipelines** Between Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services. Between Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers. Furthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025. **Trello** Between Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments. **Login** Between Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access. The issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed. **Statuspage** Between Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps. ### REMEDIAL ACTION PLAN & NEXT STEPS We have completed the following critical actions designed to help prevent cross-region impact from similar issues: * Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage. * Fixed the issue that prevented timely failover of the identity service which impacted new login sessions. * Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages. Additionally, we are prioritizing the following improvement actions: * Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service. Although disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues. We recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance. Thanks, Atlassian Customer Support

1. 12 de septiembre de 2025 a las 20:43 UTCmonitoring

   From 5:03 AM ET to 4:15 PM ET, some customers were unable to record Zoom meetings using Loom Meeting Recordings. Attempts made during this time may appear in your library but will not be playable, as no recording was captured. Unfortunately, these recordings cannot be recovered. We have released a fix and we are monitoring recovery.

2. 12 de septiembre de 2025 a las 22:14 UTCresolved

   The issue has been resolved and the service is operating normally.

1. 8 de septiembre de 2025 a las 21:46 UTCresolved

   From 5:20AM to 3:45PM UTC today some customers using the Loom Chrome Extension experienced issues with recording. Looms recorded during this time may show up in the library but will not be playable. Unfortunately we are unable to recover these videos. If you are still experiencing this issue please make sure you are recording with extension version 5.5.121.

1. 15 de agosto de 2025 a las 19:35 UTCidentified

   We are investigating reports of issues for Loom customers. Including names showing as IDs. We will provide more details once we identify the cause.

2. 15 de agosto de 2025 a las 19:50 UTCmonitoring

   We have identified the cause of the issues and we are monitoring recovery.

3. 15 de agosto de 2025 a las 19:58 UTCresolved

   Between 18:45 and 19:35 UTC we experienced degraded functionality for Loom. The issue has been resolved and the service is operating normally.

1. 14 de abril de 2025 a las 19:07 UTCidentified

   Customers are unable to choose a monthly plan when upgrading or purchasing from loom.com. We are investigating this issue.

2. 14 de abril de 2025 a las 19:30 UTCmonitoring

   A fix has been implemented and we are monitoring the results

3. 14 de abril de 2025 a las 19:34 UTCresolved

   This issue is now resolved and customers can checkout as expected.