Historial de interrupciones de Linode

1. 24 de agosto de 2026 a las 21:52 UTCinvestigating

   Nuestro equipo está investigando un problema que afecta al servicio de almacenamiento de objetos en US-SEA. Durante este tiempo, los usuarios pueden experimentar errores intermitentes de 5xx con este servicio.

2. 25 de agosto de 2026 a las 0:31 UTCinvestigating

   Seguimos investigando esta cuestión.

3. 25 de agosto de 2026 a las 0:55 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

4. 25 de agosto de 2026 a las 1:11 UTCresolved

   No hemos observado ningún problema adicional con el servicio de almacenamiento de objetos, y ahora consideraremos este incidente resuelto. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

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

1. 21 de agosto de 2026 a las 17:23 UTCinvestigating

   Nuestro equipo está investigando una nueva cuestión de servicio que nos afecta al mar (Seattle, WA). Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 21 de agosto de 2026 a las 21:59 UTCresolved

   En este momento hemos podido corregir el problema y el servicio ha reanudado el funcionamiento normal.

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

1. 14 de agosto de 2026 a las 20:13 UTCinvestigating

   Nuestro equipo está investigando un problema que afecta la conectividad en nuestro centro de datos IT-MIL (Milan). Durante este tiempo, los usuarios pueden experimentar intervalos de conexión intermitentes y errores para todos los servicios desplegados en este centro de datos. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 14 de agosto de 2026 a las 21:18 UTCinvestigating

   Seguimos investigando esta cuestión. Compartiremos actualizaciones adicionales ya que tenemos más información.

3. 14 de agosto de 2026 a las 21:30 UTCresolved

   No hemos observado ningún problema adicional de conectividad en nuestro centro de datos IT-MIL (Milan) y ahora consideraremos este incidente resuelto. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

4. 18 de agosto de 2026 a las 19:02 UTCpostmortem

   El 14 de agosto de 2026, a partir de las 17:30 UTC, durante un evento en nuestro centro de datos IT-MIL \(Milan\), se desencadenaron múltiples alertas indicando que múltiples hosts en este centro de datos se hicieron inalcanzables. Akamai comenzó inmediatamente a investigar la cuestión y a trabajar para restaurar los anfitriones afectados. Durante la ventana de impacto, los clientes habrían experimentado intervalos de conexión intermitentes y errores en todos los servicios desplegados en este centro de datos. Restituimos los hosts impactados y fijamos los problemas de conectividad a las 21:20 UTC el 14 de agosto de 2026. Todavía estamos investigando la causa de la condición de fracaso. Nos comprometemos a prevenir futuros incidentes y llevaremos a cabo una investigación exhaustiva de por qué los anfitriones se volvieron inalcanzables, aplicando medidas para mejorar la estabilidad y la fiabilidad. Este resumen ofrece una visión general de nuestra comprensión actual del incidente dada la información disponible. Nuestra investigación está en curso, y cualquier información aquí presente está sujeta a cambios.

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

1. 13 de agosto de 2026 a las 21:13 UTCinvestigating

   Nuestro equipo está investigando un problema que afecta la creación de agrupaciones Linode Kubernetes Engine Enterprise (LKE-E) en el centro de datos IAD2 - Washington. Esta es una continuación de la cuestión comunicada anteriormente. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 13 de agosto de 2026 a las 23:02 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

3. 13 de agosto de 2026 a las 23:24 UTCresolved

   Este incidente ha sido resuelto.

4. 18 de agosto de 2026 a las 20:32 UTCpostmortem

   Entre 17:25 UTC y 22:50 UTC el 13 de agosto de 2026, los clientes de Linode Kubernetes Engine Enterprise \(LKE-E\) que intentan desplegar instancias de Linode dedicadas G7 en nuestro centro de datos de Washington \(IAD2\), recibieron 403 mensajes de error. La carga de trabajo activa y los casos en curso no se vieron afectados por esta cuestión. Nuestra investigación reveló que, si bien la capacidad total de hardware físico en el IAD2 era suficiente, la solicitud de provisión provocó un fallo de control de derechos debido a un umbral inicial de ubicación de host blando. Akamai resolvió la cuestión aumentando el límite de Linode-per-host de 5 a 20 en IAD2. Las capacidades de despliegue completo fueron restauradas y estabilizadas a las 22:50 UTC. Para evitar que la recurrencia avance, implementaremos alertas específicas para cuestiones de derecho y capacidad, directamente vinculadas a los corredores de respuesta para una rápida rehabilitación. Además, estamos construyendo un panel centralizado de visión general de la capacidad para seguir proactivamente las salas regionales. Este resumen ofrece una visión general de nuestra comprensión actual del incidente dada la información disponible. Nuestra investigación está en curso y cualquier información aquí presente está sujeta a cambios.

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

1. 13 de agosto de 2026 a las 18:46 UTCinvestigating

   Nuestro equipo está investigando un nuevo problema de servicios que afecta a la API en todas las regiones. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 13 de agosto de 2026 a las 19:58 UTCmonitoring

   A partir de 19:30 UTC ha podido corregir el problema que afecta a API en todas las regiones. Estaremos monitoreando esto para asegurar que el servicio permanezca estable. Si todavía está experimentando problemas y no puede abrir un ticket de soporte, por favor llámenos al 855-454-6633 (+1-609-380-7100 Intl.), o envíe un correo electrónico a [email protected].

3. 13 de agosto de 2026 a las 19:59 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

4. 14 de agosto de 2026 a las 0:26 UTCresolved

   Este incidente ha sido resuelto.

5. 17 de agosto de 2026 a las 17:38 UTCpostmortem

   On August 13th, 2026, at approximately 18:15 UTC, Akamai observed a brief service outage affecting [ api.linode.com ](http://api.linode.com). La interrupción total del servicio duró aproximadamente 3 minutos, concluyendo a las 18:18 UTC. Tras la restauración de la conectividad inicial, latencia elevada de respuesta a la API persistió a través de 19:06 UTC, causando tiempos de respuesta más lentos y retrasos intermitentes para los clientes que interactúan con los servicios de API. Para abordar el impacto del rendimiento, los equipos de ingeniería de Akamai identificaron una discrepancia de configuración en el nodo de infraestructura de caché secundario que le impidió absorber toda la carga de tráfico después de la falla. Los ingenieros completaron una migración controlada y trasladaron el tráfico de caché hacia el host primario. Tras este cambio, latencia de la API disminuyó rápidamente a niveles operativos normales. La condición inicial fue desencadenada por un reinicio inesperado del anfitrión físico del nodo de caché primario. Si bien la infraestructura redundante estaba activa, el nodo secundario no pudo procesar el tráfico sin trabas, causando la degradación del rendimiento prolongada. Nuestros equipos de ingeniería están llevando a cabo una investigación de seguimiento de los mecanismos de falla para optimizar las velocidades de ejecución y alinear los ajustes de configuración en los nodos redundantes, asegurando que los sistemas secundarios puedan manejar el tráfico sin problemas en futuros eventos. Este resumen ofrece una visión general de nuestra comprensión actual del incidente dada la información disponible. Nuestra investigación está en curso y cualquier información aquí presente está sujeta a cambios.

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

1. 13 de agosto de 2026 a las 16:16 UTCinvestigating

   Nuestro equipo está investigando un problema que afecta al motor Linode Kubernetes (LKE). Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 13 de agosto de 2026 a las 16:30 UTCmonitoring

   En este momento hemos podido corregir los problemas que afectan al servicio LKE. Estaremos monitoreando esto para asegurarnos de que permanezca estable. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

3. 13 de agosto de 2026 a las 17:54 UTCresolved

   No hemos observado ningún problema adicional con el servicio LKE, y ahora consideraremos este incidente resuelto. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

4. 17 de agosto de 2026 a las 21:30 UTCpostmortem

   A partir de aproximadamente 14:50 UTC el 13 de agosto de 2026, los clientes que intentaron suministrar Linode Kubernetes Engine Enterprise \(LKE-E\) clusters en el centro de datos IAD2 no pudieron. Identificamos que el problema se debió a la exclusión de dos componentes en IAD2 en una actualización reciente de la versión de software que dio lugar a un desajuste de la API. Actualizamos los componentes identificados para llevarlos sincronizados con el estado esperado. Esto mitigó la cuestión a aproximadamente 16:00 UTC el 13 de agosto de 2026. Para evitar que este problema ocurra en el futuro, estamos revisando los procesos de actualización de software LKE para asegurar que todos los componentes incluyan actualizaciones de versiones completas antes de ser reintroducidos al servicio durante actualizaciones de software de plataforma. Este resumen ofrece una visión general de nuestra comprensión actual del incidente dada la información disponible. Nuestra investigación está en curso y cualquier información aquí presente está sujeta a cambios.

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

1. 14 de agosto de 2026 a las 15:46 UTCresolved

   El 13 de agosto de 2026, entre aproximadamente 14:00-16:30 UTC, observamos fallos y retrasos intermitentes al suministrar nuevos grupos LKE-E en la región de Seattle (SEA1). El problema que afecta al servicio LKE-E en Seattle autocorregido a aproximadamente 16:30 UTC, y no hemos observado una recurrencia desde entonces. Estamos investigando activamente la causa. Seguiremos vigilando el servicio para la estabilidad. Si experimenta algún problema con este servicio, por favor abra un ticket de Soporte para asistencia.

2. 21 de agosto de 2026 a las 13:13 UTCpostmortem

   On August 13, 2026, between approximately 14:30 and 16:30 UTC, Akamai experienced an issue affecting Linode Kubernetes Engine Enterprise \(LKE-E\) cluster provisioning and deployment in the Seattle \(SEA1\) region. During this time, customers attempting to create new clusters encountered failures or delays. In some cases, clusters were created but nodes were not fully provisioned, while in others, the control plane responsible for managing the cluster could not be deployed. Akamai identified the issue through customer reports, which was then validated by reproducing the failures in Seattle-based test clusters. Other regions continued to operate normally, and no existing customer workloads were impacted. By around 16:30 UTC on August 13, 2026, cluster provisioning and deployment in the Seattle region returned to normal, allowing new cluster creations to proceed without issue. After recovery, we monitored the region for several days and began a technical investigation into the service disruption. Initial findings indicate a correlation between the issue and a recent network configuration update that occurred at approximately 14:30 UTC and was rolled back at approximately 14:45 UTC. Our current hypothesis suggests that a timing conflict during the cluster provisioning process may have triggered the failures. We are continuing to investigate the technical details to confirm the root cause. We are continuing to investigate the technical details behind this issue and are working to ensure it does not recur. We will also review the scope of affected data centers and track corrective actions. This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

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

1. 10 de agosto de 2026 a las 17:15 UTCinvestigating

   Nuestro equipo está investigando un número de arriba que impacta las implementaciones Ubuntu. Esto puede afectar la capacidad de instalar paquetes y actualizaciones de seguridad en todos los sistemas Ubuntu.

2. 11 de agosto de 2026 a las 23:35 UTCinvestigating

   Seguimos investigando esta cuestión. Se contrata a los expertos pertinentes en materia de asuntos. Las actualizaciones posteriores sobre el estado de mitigación se publicarán a medida que se avance.

3. 12 de agosto de 2026 a las 3:29 UTCidentified

   Hemos identificado la causa de la cuestión y se está aplicando una solución. Proporcionaremos una actualización tan pronto como la solución esté en su lugar.

4. 21 de agosto de 2026 a las 18:40 UTCresolved

   Podemos confirmar que el problema fue mitigado a las 06:30 UTC el 20 de agosto de 2026 y el servicio ha reanudado las operaciones normales.

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

1. 31 de julio de 2026 a las 17:49 UTCinvestigating

   Nuestro equipo está investigando la pérdida de paquetes en algunos caminos de los centros de datos in-maa en-bom-2 en la región de Estados Unidos. Durante este tiempo, los usuarios pueden experimentar timeouts de conexión y errores con servicios que atraviesan entre las regiones de India y Estados Unidos. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 31 de julio de 2026 a las 18:25 UTCidentified

   Nuestro equipo ha identificado la causa de la pérdida de paquetes a nuestros centros de datos estadounidenses. Trabajamos con nuestro proveedor para resolver este problema y proporcionaremos una actualización tan pronto como la solución esté en marcha.

3. 4 de agosto de 2026 a las 18:36 UTCidentified

   We are continuing to work with our upstream provider to resolve the packet loss affecting some paths between the in-maa and in-bom-2 data centers and the US region. We will share further updates as progress continues.

4. 5 de agosto de 2026 a las 1:34 UTCresolved

   At this time the upstream provider has been able to correct the issue causing packet loss on some routes from the in-maa & in-bom-2 data centers into the US region and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

5. 5 de agosto de 2026 a las 17:49 UTCpostmortem

   On July 31, 2026, at approximately 10:00 UTC, Akamai observed intermittent network losses affecting compute users accessing US locations from our India sites \(MAA and BOM\). Customers’ services in North America, particularly the Miami data center region, experienced increased latency, intermittent connectivity issues, slower data transfers, and difficulty reaching certain applications or services. Performance was unstable, with periods of normal operation followed by disruptions. To address the issue, Akamai applied a deny-all policy to the impacted upstream provider transit link, redirecting traffic around the impacted routes. Despite this mitigation, ongoing IPv6 losses occurred due to congestion between two alternative upstream providers, impacting some users. One provider acknowledged a bottleneck in the Asia region, and the alternate provider worked to reroute traffic away from affected links.  The initial impacted service provider confirmed that two fiber cuts in Mexico caused congestion on the impacted routes. One of these fiber cuts was resolved at 23:43 UTC on July 31, 2026, and no further issues were observed following this mitigation.  This summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.

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

1. 28 de julio de 2026 a las 18:14 UTCinvestigating

   Nuestro equipo está investigando un problema que afecta al servicio Block Storage en varias regiones del centro de datos. Este problema afecta en gran medida los volúmenes de almacenamiento de bloques adjuntos y desvinculados. Durante este tiempo, los usuarios pueden experimentar colgamientos de volumen adjunto/desprender, timeouts y errores con este servicio. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 28 de julio de 2026 a las 19:27 UTCidentified

   Nuestro equipo ha identificado el problema que afecta al servicio Block Storage en nuestros centros de datos. Trabajamos rápidamente para implementar una solución, y proporcionaremos una actualización tan pronto como la solución esté en su lugar.

3. 28 de julio de 2026 a las 20:17 UTCidentified

   Quisiéramos actualizar que después de la investigación adicional, el impacto se manifestaría en trabajos de acogida retrasados y a veces fallidos, lo que podría incluir muchas acciones diferentes en Linodes y no sólo impactar los volúmenes de almacenamiento de bloques adjuntos y desvinculados como mencionamos en nuestra actualización inicial, hemos actualizado el título para reflejar el impacto actualizado. Trabajamos rápidamente para implementar una solución, y proporcionaremos una actualización tan pronto como la solución esté en su lugar.

4. 28 de julio de 2026 a las 22:51 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

5. 29 de julio de 2026 a las 12:27 UTCresolved

   No hemos observado ningún problema adicional de degradación del desempeño de los trabajos de acogida, y ahora vamos a considerar este incidente resuelto. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

6. 31 de julio de 2026 a las 18:57 UTCpostmortem

   On 27 July 2026 at 3:30 UTC, Akamai observed an increase in errors when connecting to the Linode hosting database, primarily affecting Block Storage volume attacheds. Esto dio lugar a fallos de trabajo de host y a un impacto limitado del cliente, con algunos usuarios que experimentan mensajes de error y flujos de trabajo interrumpidos. Las tasas de timeout elevadas se observaron en registros para ciertas ubicaciones del centro de datos, coincidiendo con la salida incremental de una nueva bandera de características. La investigación inicial reveló caídas de paquetes intermitentes desde el proxy de la base de datos a los huéspedes del cliente durante el apretón de manos TLS. The current theory suggests that a DDoS-protection limit related to path MTU packet too big ICMP messages was reached. Cuando el proxy envió paquetes TCP con un MTU grande, los mensajes ICMP esperados fueron retirados por los routers de la puerta de entrada de Dallas debido a superar la tasa permitible configurada. Esto causó conexiones proxy TCP proxy de la base de datos a tiempo de salida para Compute Hosts. El problema fue desencadenado por la habilitación de la nueva bandera de características, que cambió el camino de enrutamiento y removió la fijación de MTU antes de que los paquetes llegaran a las pasarelas. Para mitigar el problema, Akamai revisó el cambio de red reciente en los sitios de Compute afectados, comenzando a las 20:50 UTC. A partir de las 22:57 UTC, la tasa de servicios se reinicia a niveles preincidentes. Akamai también está planeando un cambio para aumentar el umbral permitido para paquetes demasiado grandes mensajes de ICMP. Este resumen ofrece una visión general de nuestra comprensión actual del incidente dada la información disponible. Nuestra investigación está en curso y cualquier información aquí presente está sujeta a cambios.

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

1. 20 de julio de 2026 a las 1:52 UTCinvestigating

   Nuestro equipo está investigando un problema de conectividad que afecta a Linodes en la región de Italia (Milan). Durante este tiempo, los Linodes existentes en este lugar pueden ser inalcanzables. Tenga en cuenta que la creación de nuevos Linodes funciona normalmente y no se ve afectada.

2. 20 de julio de 2026 a las 2:56 UTCinvestigating

   Seguimos investigando esta cuestión. Proporcionaremos la próxima actualización a medida que avancemos.

3. 20 de julio de 2026 a las 3:12 UTCinvestigating

   Nuestro equipo ha identificado el problema que afecta la conectividad en nuestro centro de datos de Milán (Italia). Trabajamos rápidamente para implementar una solución, y proporcionaremos una actualización tan pronto como la solución esté en su lugar.

4. 20 de julio de 2026 a las 3:20 UTCmonitoring

   En este momento hemos podido corregir los problemas que afectan la conectividad en nuestro centro de datos de Milán (Italia). Estaremos monitoreando esto para asegurarnos de que permanezca estable. Si sigues experimentando problemas, por favor, abre un ticket de asistencia.

5. 20 de julio de 2026 a las 4:10 UTCresolved

   No hemos observado ningún problema adicional de conectividad en nuestro centro de datos de Milán (Italia) y ahora consideraremos este incidente resuelto. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

6. 20 de julio de 2026 a las 5:45 UTCpostmortem

   A partir de las 00:33 UTC el 20 de julio de 2026, algunos anfitriones en el centro de datos de Milán, Italia no estaban disponibles, lo que impactó el acceso al cliente a Linodes. The investigation identified that this issue occurred during scheduled router firmware updates. Si bien seguimos un proceso de actualización gradual para prevenir la interrupción de los servicios, una intersección inesperada de las actividades de mantenimiento simultáneo llevó a una pérdida temporal de conectividad de red para los anfitriones afectados. El servicio fue completamente restaurado por 02:16 UTC el 20 de julio de 2026, y todos los sistemas están operando como se espera. Internamente, estamos revisando nuestros procedimientos de gestión del cambio y programación de mantenimiento para asegurar una mejor coordinación e impedir cuestiones similares en el futuro. Nos disculpamos por el impacto y gracias por su paciencia y apoyo continuo. Nos comprometemos a hacer mejoras continuas para mejorar nuestros sistemas e impedir la recurrencia. Este resumen ofrece una visión general de nuestra comprensión actual del incidente dada la información disponible. Nuestra investigación está en curso, y cualquier información aquí presente está sujeta a cambios.

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

1. 18 de julio de 2026 a las 3:34 UTCinvestigating

   Nuestro equipo está investigando un problema que afecta al servicio de almacenamiento de objetos. Durante este tiempo, los usuarios pueden experimentar timeouts de conexión y errores con este servicio.

2. 18 de julio de 2026 a las 3:54 UTCidentified

   Nuestro equipo ha identificado la cuestión que afecta al servicio de almacenamiento de objetos. Trabajamos rápidamente para implementar una solución, y proporcionaremos una actualización tan pronto como la solución esté en su lugar.

3. 18 de julio de 2026 a las 4:36 UTCresolved

   No hemos observado ningún problema adicional con el servicio de almacenamiento de objetos, y ahora consideraremos este incidente resuelto. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

4. 21 de julio de 2026 a las 15:26 UTCpostmortem

   El 18 de julio de 2026, entre aproximadamente 00:30 UTC y 04:00 UTC, los usuarios podrían haber experimentado errores de 5xx mientras intentan crear un nuevo cubo en el almacén de objetos para los puntos finales siguientes. * [us-ord-1.linodeobjects.com](http://us-ord-1.linodeobjects.com) * [us-lax-1.linodeobjects.com](http://us-lax-1.linodeobjects.com) * [us-iad-1.linodeobjects.com](http://us-iad-1.linodeobjects.com) * [us-sea-1.linodeobjects.com](http://us-sea-1.linodeobjects.com) * [fr-par-1.linodeobjects.com](http://fr-par-1.linodeobjects.com) La cuestión comenzó cuando la infraestructura que apoyaba el almacenamiento de objetos entró en un estado degradado en todos los nodos. Esto impidió que el servicio procesara solicitudes, lo que dio lugar a fallos durante las operaciones de creación de cubos. Para mitigar el impacto, hemos aplicado una solución en el sistema de backend responsable de la creación de cubos. The impact was mitigated following this action. Nuestros expertos en materia de temas están investigando la causa raíz y adoptarán medidas preventivas apropiadas. Nos disculpamos por el impacto y apreciamos su paciencia y apoyo continuo. Estamos haciendo cambios de configuración y operativos en nuestros sistemas para ayudar a evitar que esto suceda de nuevo, y seguimos comprometidos con la mejora continua. Este resumen proporciona una visión general de nuestra comprensión actual del incidente, dada la información disponible. Nuestra investigación está en curso, y cualquier información aquí presente está sujeta a cambios.

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

1. 16 de julio de 2026 a las 1:24 UTCresolved

   Nuestro equipo investigó un problema que afectó la conectividad en nuestro centro de datos entre 21:20 UTC y aproximadamente 23:28 UTC el 15 de julio de 2026. Durante esta ventana, los usuarios pueden haber experimentado un rendimiento de redes degradados y una pérdida de paquetes para los servicios de Compute desplegados en esta región. La cuestión se resolvió después de implementar una solución. Continuamos trabajando con nuestro proveedor de servicios de terceros para confirmar la causa raíz, ya que las pruebas iniciales apuntan a una salida de conexión cruzada del campus (fibra oscura) en su infraestructura.

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

1. 14 de julio de 2026 a las 12:21 UTCinvestigating

   Nuestro equipo está investigando un nuevo problema de servicio que afecta a la API y CLI. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 14 de julio de 2026 a las 12:58 UTCidentified

   Nuestro equipo ha identificado el problema que afecta a Cloud Manager y API. Trabajamos rápidamente para implementar una solución, y proporcionaremos una actualización tan pronto como la solución esté en su lugar.

3. 14 de julio de 2026 a las 13:11 UTCmonitoring

   En este momento hemos podido corregir el problema que afecta a Cloud Manager y API. Estaremos monitoreando esto para asegurar que el servicio permanezca estable. Si todavía está experimentando problemas y no puede abrir un ticket de soporte, por favor llámenos al 855-454-6633 (+1-609-380-7100 Intl.), o envíe un correo electrónico a [email protected].

4. 14 de julio de 2026 a las 18:36 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

5. 14 de julio de 2026 a las 19:26 UTCresolved

   No hemos observado ningún problema adicional con Cloud Manager, API o CLI, y ahora consideraremos este incidente resuelto. Si continúas experimentando problemas, ponte en contacto con nosotros al 855-454-6633 (+1-609-380-7100 Intl.), o envía un correo electrónico a [email protected] para recibir asistencia.

6. 16 de julio de 2026 a las 18:13 UTCpostmortem

   El 14 de julio de 2026, a las 10:57 UTC, Akamai identificó un aumento de 502 errores y latencia afectando a los clientes usando el Linode API, CLI y Cloud Manager. Esta perturbación dio lugar a un impacto moderado del servicio, ya que los clientes reportaron altas tasas de error. Nuestra investigación inicial trazó la cuestión a latencia con los servicios de IAM, que se resolvió, pero persistieron errores elevados. Los expertos en materia de materias pertinentes determinaron además que el incidente fue provocado por un retroceso manual al balanceador de carga primaria Cloud IAM del balanceador de carga secundario. Esta acción fue impulsada por una alerta de advertencia indicando que el balanceador de carga secundario estaba actuando como el maestro protegido. El proceso manual de inicio y paración de los servicios para iniciar el fallo difiere del proceso automatizado y condujo a una cascada de conexiones GRPC estables, causando un aumento de latencia y errores de API. Reiniciar los servidores de API despejó las conexiones de estancamiento y restauró operaciones normales. El impacto del cliente fue mitigado por aproximadamente 13:10 UTC el 14 de julio de 2026. Para evitar la recurrencia, Akamai está investigando por qué el fallo manual causó este comportamiento. El equipo está considerando la posibilidad de implementar un comando de drenaje para limpiar las conexiones de GRPC durante el desvío y establecer alertas para detectar las conexiones fijas para una intervención proactiva. Sin embargo, el enfoque inmediato sigue siendo entender la causa raíz, con alerta y automatización planeadas para fases posteriores. Varios clientes han confirmado la resolución en sus despliegues. Akamai seguirá vigilando la salud del sistema y esperará más comentarios de los clientes antes de declarar la recuperación completa. Este resumen ofrece una visión general de nuestra comprensión actual del incidente dada la información disponible. Nuestra investigación está en curso y cualquier información aquí presente está sujeta a cambios.

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

1. 13 de julio de 2026 a las 18:29 UTCidentified

   Nuestro equipo ha identificado una nueva cuestión de servicios que afecta a los puestos de acogida de algunos anfitriones en todas las regiones. La conectividad de Linode es *no impactada*, pero algunos trabajos de nivel de host, como copias de seguridad o intentos de alimentar sus servicios pueden retrasarse. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 13 de julio de 2026 a las 19:54 UTCresolved

   Este incidente ha sido resuelto.

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

1. 9 de julio de 2026 a las 16:57 UTCinvestigating

   Nuestro equipo está investigando un nuevo problema de servicio que afecta a los logins de Cloud Manager. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 9 de julio de 2026 a las 17:24 UTCinvestigating

   Seguimos investigando esta cuestión. Proporcionaremos una actualización dentro de los próximos 30 minutos.

3. 9 de julio de 2026 a las 17:49 UTCmonitoring

   En este momento hemos podido corregir el problema que afecta a los logins de Cloud Manager. Estaremos monitoreando esto para asegurar que el servicio permanezca estable. Si todavía está experimentando problemas y no puede abrir un ticket de soporte, por favor llámenos al 855-454-6633 (+1-609-380-7100 Intl.), o envíe un correo electrónico a [email protected].

4. 9 de julio de 2026 a las 18:21 UTCresolved

   No hemos observado ningún problema adicional con los logins de Cloud Manager y ahora consideraremos este incidente resuelto. Si continúas experimentando problemas, ponte en contacto con nosotros al 855-454-6633 (+1-609-380-7100 Intl.), o envía un correo electrónico a [email protected] para recibir asistencia.

5. 10 de julio de 2026 a las 12:30 UTCpostmortem

   On July 9, 2026, at 15:43 UTC, customers were unable to login to [cloud.linode.com](http://cloud.linode.com) using username and password. Los clientes estaban recibiendo el mensaje de error de "contraseña incorrecta". La investigación reveló que la cuestión se debía a una cuestión de certificado interno. Para mitigar el impacto, fijamos el número de certificados en los servidores impactados a las 17:24 UTC el 9 de julio de 2026. Después de monitorear nuestros sistemas durante algún tiempo, confirmamos que la cuestión se resolvió completamente. Akamai desplegará una solución permanente para evitar que se repita la cuestión.

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

1. 6 de julio de 2026 a las 18:04 UTCinvestigating

   Our team is investigating an emerging service issue affecting Managed Databases across all regions. Customers may experience latency when provisioning new databases or deleting existing ones. There is no observed impact to the performance or availability of active, running databases at this time. We will provide updates as more information becomes available.

2. 7 de julio de 2026 a las 15:31 UTCresolved

   This incident has been resolved.

1. 1 de julio de 2026 a las 17:21 UTCidentified

   Our team is investigating a service issue that affects the auto configuration of networking on Linodes by Network Helper to fail. During that time, some users may have Linodes provision but appear to have no connectivity. This also can impact Linodes created by the Linode Kubernetes Engine and impact autoscaling or provisioning of clusters. Customers can still manually configure networking via the LISH console to mitigate this issue. Please see our guide on manual network configuration on a Compute Instance . We will share additional updates as we have more information.

2. 1 de julio de 2026 a las 18:09 UTCmonitoring

   A fix has been implemented to resolve the automated network configuration issue on Linodes using Network Helper. We recommend rebooting your Linode to restore full network functionality. We are actively monitoring the results to ensure continued stability.

3. 1 de julio de 2026 a las 18:28 UTCresolved

   We haven’t observed any additional issues with the Linode Automated Networking service, and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

1. 30 de junio de 2026 a las 18:54 UTCinvestigating

   Our team is investigating an emerging issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. During this time, users may experience connection timeouts and errors with this service. We will share additional updates as we have more information.

2. 30 de junio de 2026 a las 19:55 UTCinvestigating

   We are continuing to investigate this issue.

3. 30 de junio de 2026 a las 20:36 UTCidentified

   Our team has identified the issue affecting the Block Storage service in our Singapore Expansion, SP (sg-sin-2) data center. We are working quickly to implement a fix, and we will provide an update as soon as the solution is in place.

4. 30 de junio de 2026 a las 21:36 UTCidentified

   We are continuing to work on a fix for this issue.

5. 30 de junio de 2026 a las 22:10 UTCmonitoring

   At this time we have been able to correct the issues affecting the Block Storage service. We will be monitoring this to ensure that it remains stable. If you continue to experience problems, please open a Support ticket for assistance.

6. 30 de junio de 2026 a las 23:22 UTCresolved

   We haven’t observed any additional issues with the Block Storage service in Singapore Expansion, SP (sg-sin-2), and will now consider this incident resolved. If you continue to experience problems, please open a Support ticket for assistance.

7. 2 de julio de 2026 a las 16:29 UTCpostmortem

   On June 30, 2026, between approximately 17:30 UTC and 21:45 UTC, users may have experienced connection timeouts and errors related to the Block Storage service in Singapore Expansion, SP \(sg-sin-2\). The issue began when one host in the cluster was taken down for maintenance while another host unexpectedly encountered network issues. A configuration issue also contributed to the impact. These factors led to a degraded state that affected performance and, to a limited extent, data availability. We mitigated the impact to customers at 21:45 UTC on June 30, 2026 by correcting the network, configuration and cluster issues. We apologize for the impact and appreciate your patience and ongoing support. We are making configuration and operational changes to our systems to help prevent this from happening again, and remain committed to continuous improvement. This summary provides an overview of our current understanding of the incident, given the information available. Our investigation is ongoing, and any information herein is subject to change.

1. 26 de junio de 2026 a las 17:35 UTCinvestigating

   Nuestro equipo está investigando un problema que afecta a la Metrics de Pulso de la Nube (Metrics de CLP), afectando específicamente la presentación de informes de medición de bases de datos gestionadas. La cuestión parece ser intermitente. Compartiremos actualizaciones adicionales ya que tenemos más información.

2. 26 de junio de 2026 a las 18:19 UTCinvestigating

   Seguimos investigando esta cuestión. Compartiremos actualizaciones adicionales ya que tenemos más información.

3. 26 de junio de 2026 a las 19:08 UTCinvestigating

   Seguimos investigando esta cuestión. Proporcionaremos más actualizaciones ya que tenemos más información.

4. 26 de junio de 2026 a las 20:04 UTCinvestigating

   Seguimos investigando esta cuestión.

5. 26 de junio de 2026 a las 21:13 UTCmonitoring

   No hemos observado una recurrencia del problema que afecta a la medición del pulso de la nube (Metrics de ALP) durante varias horas. Nuestro equipo seguirá vigilando el servicio de cerca mientras investigamos la causa subyacente. Si continúa experimentando problemas, por favor, abra un ticket de Soporte para asistencia.

6. 30 de junio de 2026 a las 0:02 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

7. 8 de julio de 2026 a las 12:26 UTCresolved

   No hemos observado ningún problema adicional con el servicio Cloud Pulse Metrics (CLP Metrics), y ahora consideraremos este incidente resuelto. Si sigues experimentando problemas, por favor, abre un ticket de Soporte para asistencia.

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