Historial de interrupciones de Technolutions

1. 14 de mayo de 2026 a las 16:29 UTCinvestigating

   Estamos observando mayor latencia de disco para bases de datos alojadas en el grupo MORA. Comenzaremos una falla en la infraestructura secundaria mientras investigamos más.

2. 14 de mayo de 2026 a las 17:20 UTCmonitoring

   Comenzamos una falla a las 12:30 pm del Este El tiempo, el fallo fue sin problemas, y las bases de datos funcionan dentro de los rangos de rendimiento esperados. Comenzaremos un fracaso más tarde esta noche después de un reinicio de la infraestructura de servicio primario. Seguiremos vigilando para asegurar que los niveles de rendimiento sigan siendo los límites previstos.

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

1. 4 de mayo de 2026 a las 5:14 UTCinvestigating

   Estamos investigando una cuestión que está afectando la disponibilidad de ciertas bases de datos. Proporcionaremos actualizaciones como las tenemos.

2. 4 de mayo de 2026 a las 5:46 UTCinvestigating

   Las bases de datos afectadas están en línea y están disponibles de nuevo. Seguimos investigando la causa de esta interrupción.

3. 4 de mayo de 2026 a las 6:53 UTCresolved

   La interrupción de la disponibilidad se debió a la pérdida de quórum en el grupo de fracasos. Seguimos investigando las interrupciones periódicas de la red que se han producido tras las recientes mejoras a la infraestructura de la base de datos y los sistemas operativos. Mientras tanto, hemos endurecido aún más la configuración del grupo para evitar fallos e interrupciones no deseados.

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

1. 27 de abril de 2026 a las 17:43 UTCmonitoring

   Las bases de datos de LUNA no estaban disponibles a principios de esta hora, ya que el servicio de alta disponibilidad inició una falla inesperada y se sorprendió en un bucle de failover. Los servidores de base de datos fueron actualizados este fin de semana a una versión actualizada, y estamos investigando qué papel puede ser jugar. Estamos desactivando la falla automática temporalmente como medida protectora mientras investigamos más.

2. 27 de abril de 2026 a las 21:15 UTCresolved

   No ha habido más problemas. Seguiremos operando con fallos manuales por un poco más de tiempo mientras validamos la eficacia de las fallas automáticas. También seguiremos monitoreando para cualquier otra condición que pueda resultar de las actualizaciones del servidor de bases de datos.

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

1. 26 de abril de 2026 a las 1:13 UTCinvestigating

   Estamos investigando la disponibilidad intermitente de ciertas bases de datos en la región de Estados Unidos. Algunas bases de datos todavía se están recuperando después de un fracaso en la infraestructura secundaria y tal vez no estén disponibles durante la finalización del fallo. Vamos a proporcionar actualizaciones en breve.

2. 26 de abril de 2026 a las 1:39 UTCmonitoring

   Todas las bases de datos afectadas recuperaron hace aproximadamente media hora. Continuamos abordando algunos problemas de conectividad interna, pero no vemos ningún impacto observable en este momento. Puede haber interrupciones breves de conexión ya que los fallos completos más adelante.

3. 26 de abril de 2026 a las 1:39 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

4. 26 de abril de 2026 a las 5:44 UTCresolved

   No ha habido efectos continuos. The incident, which primarily affected databases on the LIMA cluster, was caused by an automatic failover to secondary infrastructure. Una actualización de mantenimiento de rutina al motor de base de datos de terceros introdujo un cambio de comportamiento que, en condiciones específicas, dio lugar a un agotamiento de los hilos de los trabajadores. Al fallar, algunas bases de datos fueron más lentas para recuperarse como resultado de un agotamiento relacionado de los hilos de los trabajadores en este nodo secundario. Hemos desactivado la funcionalidad que dio lugar a este cambio conductual, como lo aconsejó el proveedor, y hemos aumentado el techo para los hilos obreros para reducir el potencial de reoccurrencia. Todo permanece estable en este momento, y seguiremos monitoreando para otras cuestiones.

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

1. 5 de diciembre de 2025 a las 20:58 UTCidentified

   Actualmente estamos investigando una cuestión intermitente que ha afectado el procesamiento de ciertas exportaciones e importaciones. Creemos que esto se debe a un problema con un SDK AWS actualizado que interactúa con una capa de almacenamiento de fondo. Hemos revertido temporalmente a la versión anterior de esta herramienta de terceros. Las importaciones que anteriormente fallaron están siendo reprocesadas ahora.

2. 11 de diciembre de 2025 a las 20:29 UTCresolved

   Hemos completado nuestro examen del incidente que afectó el procesamiento de ciertas exportaciones e importaciones el 12/5. Slate utiliza un grupo de nodos obreros para procesar trabajos de fondo. Estos nodos se actualizan periódicamente con la última versión de Slate, y en 12/5 se actualizaron a una construcción que incluía una versión más nueva de un SDK AWS de terceros. Los nodos de trabajadores emplean un mecanismo de copia de sombras que crea copias de dependencias binarias de caché local para evitar bloquear archivos de almacenamiento compartido. Este mecanismo refresca las asambleas caché sólo cuando detecta un cambio en la identidad de la asamblea, que normalmente ocurre durante actualizaciones rotatorias o versionadas. El SDK AWS actualizado introdujo un cambio estructural interno: una propiedad fue trasladada de una clase derivada a su clase base. Aunque ninguna firma de API pública cambió, la unión IL compilada lo hizo. Debido a que la identidad de la asamblea no cambió, el caché de la fotocopia sombra no se refrescó. Como resultado, los nodos obreros intentaron ejecutar la referencia de IL a la propiedad en la clase derivada contra la versión caché anterior, causando un error de tiempo de ejecución “metodo no encontrado”. En la tarde del 12/5, revertimos los nodos obreros a la versión anterior de AWS SDK, restaurando el funcionamiento normal. Desde entonces hemos implementado mejoras a nuestra arquitectura de nodos obreros para proporcionar un aislamiento más fuerte de caché y para asegurar que las actualizaciones del SDK AWS y otras dependencias sean correctamente reconocidas, incluso cuando se produzcan cambios internos sin un cambio correspondiente en la identidad de montaje. Los nodos web utilizan un mecanismo de copia de sombras diferente y no se vieron afectados.

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

1. 11 de noviembre de 2025 a las 21:39 UTCresolved

   Aproximadamente a las 3:08pm El tiempo, la conectividad a las bases de datos alojadas en el grupo LUNA se interrumpió como resultado de un vertedero de pila de servidor de bases de datos. Aunque la conectividad generalmente se restablece en cuestión de segundos, algunas bases de datos del grupo LUNA no vieron una restauración automática de la conectividad. Por lo tanto, se inició una falla manual y a las 3:38pm Tiempo, se restableció la conectividad a todas las bases de datos del grupo LUNA. Las bases de datos sobre otros grupos no se vieron afectadas.

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

1. 20 de octubre de 2025 a las 12:07 UTCresolved

   A principios de esta mañana, aproximadamente a las 2:51 horas del Este Tiempo, AWS experimentó una interrupción del servicio que impactó ciertos componentes específicos de Slate. Mientras que la mayoría de los servicios de Slate permanecieron en línea, el lector de pizarras, la generación de PDF y otros servicios utilizando la base de datos AWS DynamoDB experimentaron altas tasas de error. Observamos la resolución completa del evento AWS por aproximadamente 5:19am Hora Oriental.

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

1. 12 de junio de 2025 a las 15:05 UTCresolved

   A principios de esta mañana, entre aproximadamente 8am y 10am Hora Oriental, los cuerpos de mensajes HTML en un subconjunto de correos programados pueden haber aparecido en blanco al enviar. Una actualización de configuración aplicada a los nodos de trabajadores de fondo resultó temporalmente en algunos de estos mensajes HTML que no se renderizan en el momento de envío. Todos los nodos del trabajador de fondo están renderizando todos los cuerpos del mensaje HTML correctamente en este momento. No se afectaron los mensajes transaccionales (por ejemplo, mensajes de confirmación de formularios o eventos) pero, debido a la naturaleza específica y aislada de este problema, lamentablemente no podemos determinar qué órganos HTML específicos podrían haber fallado en enviar correctamente. Hemos puesto en marcha salvaguardias adicionales para evitar que este tipo de problema vuelva a ocurrir durante las actualizaciones de configuración en el futuro.

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

1. 12 de marzo de 2025 a las 14:01 UTCinvestigating

   Estamos observando un aumento de latencia en el clúster ARES e iniciaremos una falla de servicio. Las conexiones a las bases de datos del grupo ARES pueden verse brevemente afectadas a medida que se redireccionan.

2. 12 de marzo de 2025 a las 14:27 UTCmonitoring

   La falla terminó con éxito y los servicios funcionan dentro de parámetros normales en este momento. Seguiremos monitoreando este clúster para asegurar el rendimiento continuo dentro de los parámetros operativos normales.

3. 12 de marzo de 2025 a las 20:04 UTCresolved

   No se han observado más casos de latencia en el grupo ARES. Como medida cautelar, restableceremos cualquier otra infraestructura que haya experimentado recientemente condiciones similares que puedan haber contribuido a la elevada latencia observada aquí.

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

1. 31 de enero de 2025 a las 17:39 UTCresolved

   El miércoles por la tarde, comenzando alrededor de las 3:40pm El tiempo, una re-sincronización del balanceador de carga de rutina dio lugar a una distribución de tráfico desequilibrada que aumentó latencia de algunas conexiones y devolvió un estado de TCP RST para algunos otros, mientras que todavía se procesan y manipulan con éxito otras conexiones dependiendo de su afinidad original del nodo. Hemos determinado que esta distribución de tráfico desequilibrada fue el resultado de un problema en los balanceadores de carga que reajustan los estatus de nodo durante una re-sincronización. Hemos resuelto el problema con los balanceadores de carga para evitar que esto vuelva a ocurrir. A las 4:00pm El tiempo, el tráfico se había redistribuido totalmente a través de los nodos y el rendimiento de la conexión había retornado a niveles esperados.

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

1. 6 de febrero de 2024 a las 13:25 UTCmonitoring

   Una actualización iniciada por AWS durante la noche a una serie de servidores Redis utilizados para la gestión de la cola de servicios de fondo ha retrasado el procesamiento de la cola de fondo cuando las colas entraron en un estado estancado. Las colas retrasadas están procesando ahora y terminarán pronto.

2. 6 de febrero de 2024 a las 22:14 UTCmonitoring

   A principios de esta tarde, menos del 1% de las bases de datos seguían realizando trabajos nocturnos. Las bases de datos restantes tienen empleos que suelen llevar horas durante la noche a fin de completar, y con la acumulación de empleos diurnos y los procesos de bloqueo en sus bases de datos, siguen funcionando. Separadamente, hemos ajustado el seguimiento del proceso de antecedentes para recuperarse mejor de un escenario en el que los servidores Redis se vuelven temporalmente indisponibles debido a actualizaciones de hardware o software a esos nodos.

3. 8 de febrero de 2024 a las 0:57 UTCresolved

   No se han observado problemas desde los retrasos en la cola del servicio de antecedentes nocturnos en 2/6, y todas las colas de la noche a la mañana en 2/7 realizadas como se esperaba. Seguiremos vigilando los servicios de antecedentes para asegurar el funcionamiento continuo dentro de los límites deseados.

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

1. 13 de junio de 2023 a las 19:38 UTCidentified

   AWS Lambda, que se utiliza para ciertas funciones de Slate incluyendo la conversión de documentos y la renderización de PDF, está experimentando actualmente un incidente de disponibilidad para toda su región us-east-1. AWS es consciente de la cuestión y está trabajando para lograr una resolución completa, que se espera pronto. La funcionalidad de pizarra que no confía en AWS Lambda permanece en línea y operativa en este momento. Actualizaremos este post ya que se dispone de más información.

2. 13 de junio de 2023 a las 20:57 UTCresolved

   AWS ha informado de que han resuelto el incidente que afecta a los servicios de AWS Lambda en la región de nosotros-este-1, y hemos observado una operación normal para los componentes afectados desde aproximadamente 4:37pm Hora Oriental. Este incidente ya está resuelto.

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

1. 18 de noviembre de 2022 a las 19:03 UTCinvestigating

   Actualmente estamos investigando esta cuestión.

2. 18 de noviembre de 2022 a las 19:21 UTCinvestigating

   Las operaciones normales se han restaurado en bases de datos del grupo ARES. Seguimos investigando la causa subyacente de la interrupción anterior y proporcionaremos una actualización en un futuro próximo.

3. 18 de noviembre de 2022 a las 19:21 UTCmonitoring

   A principios de esta tarde, aproximadamente a las 1:30pm El grupo de bases de datos ARES perdió conectividad a sus discos como resultado de una interrupción intermitente de la red en la infraestructura AWS. Esto dio lugar a que las bases de datos de este grupo no estuvieran disponibles mientras se restauró la conectividad de red. Todas las bases de datos están operando dentro de los rangos normales en este momento, y seguimos monitorizando el grupo ARES. Debido a que el grupo ARES alberga una base de datos de configuración primaria para Slate, este evento también puede haber impactado algunas operaciones con bases de datos en otros grupos. Estos otros grupos ya contienen réplicas de los datos de configuración, y vamos a acelerar nuestro plan programado para utilizar estas réplicas más plenamente para minimizar cualquier potencial de impacto futuro.

4. 19 de noviembre de 2022 a las 6:16 UTCresolved

   Este incidente ha sido resuelto.

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

1. 27 de septiembre de 2022 a las 16:51 UTCinvestigating

   Estamos investigando un aumento de latencia de bases de datos en el grupo LUNA, que parece ser el resultado de un aumento de latencia de disco en AWS para este nodo en particular.

2. 27 de septiembre de 2022 a las 20:10 UTCmonitoring

   A principios de hoy se observó una elevada latencia para bases de datos en el grupo LUNA. This appears to have been the result of a temporary hardware/network issue within the AWS infrastructure that resulted in increased latency for transactions log writes to the storage infrastructure. Los niveles de rendimiento han estado dentro de rangos normales durante la última hora, y seguiremos monitoreando los volúmenes de almacenamiento. Si se observa una mayor latencia de nuevo, pasaremos el cluster a nuevo hardware con AWS.

3. 28 de septiembre de 2022 a las 3:40 UTCresolved

   No se ha observado más latencia desde el evento original. Si se vuelve a observar la latencia, reabriremos este incidente y tomaremos las medidas adicionales descritas para trasladarnos a nuevos equipos.

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

1. 12 de abril de 2022 a las 20:11 UTCinvestigating

   Nuestro monitoreo de sistemas ha detectado que la conectividad a bases de datos en el grupo LUNA fue interrumpida por un outage localizado en la red AWS. Estamos preparándonos a la falta de infraestructura secundaria para restaurar la conectividad para estas bases de datos.

2. 12 de abril de 2022 a las 20:26 UTCresolved

   Una salida localizada en la red AWS resultó en una pérdida temporal de conectividad a bases de datos del grupo LUNA. Todas las bases de datos se han recuperado completamente en este momento, y cualquier latencia o los plazos residuales desaparecerán rápidamente a medida que se lean las tablas clave de bases de datos en el caché.

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

1. 1 de abril de 2022 a las 21:18 UTCidentified

   Somos conscientes de un problema que está impidiendo el retorno de la configuración normal del sistema en múltiples bases de datos. La rehabilitación está en marcha y esperamos tener todas las bases de datos de vuelta a la operación normal en los próximos minutos.

2. 1 de abril de 2022 a las 21:52 UTCmonitoring

   Las configuraciones del sistema están devolviendo valores normales en todas las bases de datos de producción en este momento, y estos sistemas se han recuperado. Actualmente se están actualizando las configuraciones del sistema para entornos de prueba. Los ambientes siguen siendo accesibles durante este refresco.

3. 1 de abril de 2022 a las 23:25 UTCresolved

   El viernes por la tarde aproximadamente a las 4:20pm Tiempo, un ingeniero aplicó una actualización de configuración del sistema demasiado amplia. Esta actualización de configuración tenía por objeto actualizar un único valor de configuración entre bases de datos. Debido al error humano, el valor se aplicó a otros valores de configuración no deseados. Mientras que las bases de datos Slate permanecieron en línea y operativas para usuarios finales y personal que ya pudo haber sido conectado, los nuevos usuarios y los inicios de sesión individuales pueden haber recibido un mensaje de error "Invalid Security Provider" debido a esta configuración inválida. Los problemas de inicio de sesión se reportaron en torno a las 4:40pm, ya que caché de configuración y más bases de datos recogieron configuraciones incorrectas del sistema, y para las 5:15pm, se estaban realizando remediaciones para revertir los cambios de configuración. A las 5:30pm, las bases de datos fueron restauradas a las configuraciones correctas y esperadas. Lamentamos profundamente este error, y hemos iniciado una auditoría interna y una revisión de nuestros protocolos para evitar que esto suceda y para asegurar que otras actualizaciones de configuración de rutina sean siempre adecuadamente abarcadas.

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

1. 19 de enero de 2022 a las 14:36 UTCinvestigating

   Actualmente estamos investigando el rendimiento degradado para bases de datos en el grupo OPUS.

2. 19 de enero de 2022 a las 16:38 UTCinvestigating

   Tras el puesto inicial, hemos hecho retroceder algunos trabajos de antecedentes (ejecución real y empleos programados) y no hemos observado más problemas de desempeño durante las dos últimas horas. Estamos aumentando lentamente el rendimiento de estos trabajos de fondo para observar el efecto en el rendimiento del sistema. No tenemos una causa raíz identificada en este momento y estamos explorando la posibilidad de un problema con hardware o infraestructura subyacentes.

3. 19 de enero de 2022 a las 19:47 UTCresolved

   No se han observado más problemas de desempeño, así que procederemos a resolver este incidente. Seguiremos monitoreando estos sistemas y si se vuelve a resolver cualquier problema de rendimiento, procederemos con nuevas mitigacións que hemos preparado para una ventana de la noche a la mañana.

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

1. 7 de diciembre de 2021 a las 18:14 UTCinvestigating

   AWS está experimentando problemas de rendimiento con su infraestructura us-east-1 hoy que está causando mayor latencia a partes de Slate. Mientras Slate permanece en línea y en funcionamiento en este momento, su problema, que está afectando a todos sus clientes en esta región, está creando algunas tasas intermitentes de latencia y error en ciertas áreas de Slate, como en el lector de pizarras mientras muestra documentos. Otras actualizaciones están disponibles en status.aws.amazon.com. Seguiremos monitoreando su página de estado para cualquier actualización.

2. 8 de diciembre de 2021 a las 2:05 UTCresolved

   AWS está informando de que ahora se han resuelto los problemas de rendimiento en su región de nosotros-este-1. Si bien todavía estamos detectando un grado de latencia de la red, parece que todos los servicios están funcionando con éxito en este momento.

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

1. 22 de octubre de 2021 a las 15:55 UTCinvestigating

   A las 11:26 am este Tiempo, se produjo un vertedero en el servidor de bases de datos ARES, lo que es una rara ocurrencia y el resultado del servidor de bases de datos que encuentra un conjunto de condiciones inestables. Las bases de datos de ARES pueden haber sido intermitentemente inaccesibles mientras el servidor se recupera. Aproximadamente a las 11:42 horas Tiempo, todas las bases de datos eran accesibles y funcionaban en condiciones normales. Actualmente estamos investigando la fuente de este basurero. Durante este evento no se afectaron otros servidores o bases de datos.

2. 22 de octubre de 2021 a las 16:56 UTCresolved

   Hemos podido confirmar que el vertedero de pila fue el resultado de un error probable en el software Microsoft SQL Server que fue activado por condiciones desconocidas. Estos eventos son excepcionalmente raros, y aunque es poco probable que este conjunto particular de condiciones se encontraría de nuevo pronto, estaremos preparando un informe de fallos para compartir con Microsoft con la esperanza de que pueda ser resuelto en una actualización futura. Seguiremos vigilando las bases de datos de ARES para asegurar que no haya reocurrencias.

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

1. 17 de octubre de 2021 a las 18:55 UTCmonitoring

   Las bases de datos pueden experimentar breves e intermitentes períodos de indisponibilidad mientras las fallas de los grupos se completan para permitir que se produzcan mejoras de seguridad y fiabilidad de terceros en las máquinas anfitrionas.

2. 17 de octubre de 2021 a las 19:37 UTCmonitoring

   El mantenimiento ha concluido para todos los grupos de bases de datos con excepción de ARES, que se tratará como parte de un proceso de mantenimiento separado debido a consideraciones especiales con ese grupo específico.

3. 18 de octubre de 2021 a las 7:28 UTCresolved

   El mantenimiento ha concluido para todos los grupos de bases de datos.

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