Una interrupción global de GitHub golpeó el sitio, la API, Actions y Copilot el 17 de agosto, mientras Redis corrige nueve fallas de seguridad de un solo lanzamiento y Cloudflare workerd extiende a ocho días su racha de versiones casi diarias.
La interrupción, iniciada a las 13:40 UTC del 17 de agosto, dejó por horas tasas de error de hasta 50% en descargas de repositorios y afectó de forma directa a GitHub Copilot.
GitHub, la plataforma de alojamiento de código que opera Microsoft, sufrió una interrupción global que comenzó a las 13:40 UTC (7:40 a.m., hora de Costa Rica) del 17 de agosto de 2026 y afectó el sitio web, la API, GitHub Actions, Pull Requests, Issues, Webhooks, la autenticación y el asistente Copilot, según reportó GeekWire. Durante buena parte del incidente, las solicitudes al sitio web y a la API fallaron a una tasa cercana al 20%, mientras que las descargas de archivos comprimidos y de contenido de repositorios en bruto llegaron a fallar hasta en un 50% de los casos, de acuerdo con las cifras que citó The Register a partir de los reportes de estado de la propia GitHub. La compañía confirmó a las 16:59 UTC que siete de los ocho servicios afectados ya estaban mitigados, unas tres horas y 19 minutos después del inicio, según The Register. La duración total del incidente varía según la fuente consultada: mientras The Register la cifra en poco más de tres horas hasta la mitigación de los servicios principales, Windows Central reportó que los problemas de autenticación en Copilot persistieron después de ese punto y calculó una interrupción de alrededor de siete horas y media hasta que GitHub cerró el caso, poco después de las 2:15 p.m., hora del Pacífico. La discrepancia importa porque GitHub es la plataforma de control de versiones más usada del mundo entre equipos de desarrollo profesional, y buena parte de las canalizaciones modernas de integración continua dependen de GitHub Actions para desplegar código: una caída ahí detiene, además del acceso al historial de un proyecto, el propio proceso de publicar software nuevo. Aun así, la tasa de error del 20% que la propia compañía reportó en el sitio y la API indica que la mayoría de las solicitudes sí se completaban durante buena parte de la ventana, un matiz que buena parte de la cobertura que tituló sin más "GitHub está caído" no siempre reflejó. GitHub no había publicado, al cierre de esta edición, un análisis de causa raíz del incidente; la compañía suele detallar ese tipo de fallas en su reporte mensual de disponibilidad. Costa Rica no publica cifras propias de cuántos equipos locales reportaron problemas, pero el horario de inicio —7:40 a.m., hora nacional— coincidió con el arranque de la jornada laboral de zonas francas tecnológicas y equipos de desarrollo que dependen de GitHub Actions para sus despliegues diarios.
El proyecto Redis publicó, el 17 de agosto de 2026 a las 16:44 UTC, la versión 8.10.1 de su base de datos en memoria, según el registro oficial de lanzamientos en GitHub. La actualización corrige nueve vulnerabilidades de seguridad: la más grave, identificada como CVE-2026-62356, es un cálculo incorrecto del tamaño de búfer durante la carga de estructuras CMSketch desde un archivo RDB, que puede provocar una escritura fuera de los límites de memoria reservada (heap out-of-bounds write); el mismo paquete corrige un uso de memoria después de liberada (use-after-free) en la lista de datos pendientes de conexiones TLS, y un defecto que permite eludir la autenticación por certificado de cliente TLS cuando el campo Common Name del certificado contiene un byte nulo incrustado, lo que trunca el nombre y puede hacer que un cliente se autentique como otro usuario con permisos distintos, según el mismo registro de cambios. El resto de los defectos corregidos afecta a los llamados Vector Sets, la estructura que Redis usa para búsquedas por similitud: dos fallas de uso de memoria después de liberada y una lectura fuera de los límites del arreglo de resultados cuando la función de búsqueda HNSW devuelve un valor negativo que el sistema interpreta como un conteo positivo muy grande. Redis publicó la misma corrección el mismo día para siete ramas de mantenimiento distintas —8.8.2, 8.6.6, 8.4.6, 8.2.9, 7.4.11, 7.2.16 y 6.2.24—, lo que indica que al menos parte de estas fallas llevaba tiempo presente en el código base, no solo en la rama más reciente. La información de esta nota proviene únicamente del registro de lanzamientos oficial de Redis en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Redis no publicó, en las notas de esta versión, una puntuación CVSS para CVE-2026-62356 ni para el resto de las fallas, lo que dificulta priorizar el parche solo con esa información. Costa Rica no publica cifras propias de adopción de Redis, pero la base de datos en memoria es una pieza estándar de arquitecturas de caché y colas de mensajes en fintech y empresas de zonas francas tecnológicas que operan backend propio en el país, a las que conviene aplicar la versión de mantenimiento correspondiente a su rama —8.10.1 o la más reciente de las siete anteriores— sin esperar a que aparezca una puntuación de severidad oficial.
cat /feed/devopscloudflareworkers.md
Las versiones 1.20260817.1 y 1.20260818.1, publicadas el 17 y el 18 de agosto, extienden a ocho días la racha de lanzamientos casi diarios del motor de Cloudflare Workers, personaje de la semana en esta sección.
> > workerd --version
> Cloudflare publicó, el 17 y el 18 de agosto de 2026, las versiones 1.20260817.1 y 1.20260818.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la séptima y la octava versión que la compañía publica en otros tantos días consecutivos, una racha que esta sección viene documentando desde el 12 de agosto. La versión del 18 de agosto corrige dos fugas de referencias fuertes en el recolector de basura (garbage collector): una que dejaba sin liberar ciclos de referencias del contexto cf en eventos de cola (tail events), y otra que abandonaba escrituras de flujos (pipe writes) sin cerrar correctamente, según el mismo registro de cambios.
> > workerd diff v1.20260817.1..v1.20260818.1
> La misma versión reemplaza referencias sin verificación de memoria por punteros más seguros en varias partes del código base, retira los adaptadores experimentales de streams que el proyecto mantenía en paralelo, y actualiza las pruebas de la plataforma web (Web Platform Tests) junto con varias dependencias, de acuerdo con el registro de cambios consultado para esta nota. La versión anterior, del 17 de agosto, no detalla cambios funcionales más allá de ajustes internos, según el mismo registro. Ocho lanzamientos seguidos sin interrupción confirman que la cadencia de workerd —generada por el flujo de integración continua propio de Cloudflare— se sostiene incluso en una semana donde la mayoría de los cambios son correcciones de memoria, no funciones nuevas.
> > echo $COSTA_RICA
> La información de esta nota proviene únicamente del registro de lanzamientos oficial de Cloudflare Workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que corren funciones de borde sobre la plataforma pueden tratar la corrección de fugas de memoria del 18 de agosto como una actualización recomendada, en particular si su código usa Durable Objects o colas basadas en eventos de cola.
Vercel publicó, el 17 y el 18 de agosto de 2026, las versiones 16.3.1-canary.22 y 16.3.1-canary.23 de Next.js, según el registro oficial de lanzamientos del proyecto en GitHub. La primera, firmada por los colaboradores lukesandberg, ztanner, mischnic y hardfist, suma mecanismos de recolección de basura (garbage collection) al motor de almacenamiento persistente de Turbopack —turbo-persistence—, entre ellos un sistema de eliminación diferida con marcadores tombstone para familias de valores múltiples y una verificación que obliga a que una tarea exista antes de poder accederse, pensada para evitar referencias a datos de caché ya descartados. La segunda, del 18 de agosto, agrega trazas (tracing) para la carga diferida de módulos de App Router y ajusta la referencia de documentación del enrutador, según el mismo registro de cambios. Estos cambios continúan directamente el trabajo que esta sección documentó el 16 y el 17 de agosto sobre el ciclo de canarios que siguió a la versión estable 16.3.1: mientras esa etiqueta ya lleva cinco días publicada, Vercel sigue sumando ajustes internos al motor de caché de Turbopack casi a diario, sin que el registro de cambios consultado para esta nota confirme todavía una fecha para la siguiente versión estable. La acumulación de mecanismos de limpieza de memoria en turbo-persistence —tombstones, verificación de existencia de tareas, plomería de eliminación— sugiere que el equipo sigue endureciendo el sistema de caché persistente antes de ampliar sus casos de uso, no que existan fallas activas reportadas públicamente. La información de esta nota proviene únicamente del registro de lanzamientos oficial de Next.js en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Next.js, pero el framework sigue siendo una opción dominante entre agencias y startups locales que construyen aplicaciones web con React, a las que conviene seguir fijando la versión estable 16.3.1 en producción y dejar estos canarios, centrados en el motor interno de caché, para entornos de prueba.
El equipo de pnpm publicó, el 18 de agosto de 2026, la séptima candidata a lanzamiento de la versión 12 (12.0.0-rc.7), según el registro oficial de lanzamientos en GitHub. El cambio central es que el archivo node_modules/.modules.yaml deja de almacenar información de registros de paquetes, lo que permite que un proyecto cambie de registro configurado sin quedar atado a los datos que guardó una instalación anterior. La misma candidata agrega la posibilidad de que un registro declare la propiedad supportsTimeField: true, lo que le permite a pnpm resolver versiones por fecha sin descargar el documento completo de metadatos del paquete, y mejora el protocolo pnpr para que las solicitudes de resolución incluyan la configuración completa del registro, los alcances (scopes) y el modo de resolución. La candidata también reemplaza la opción enableGlobalVirtualStore por un nuevo ajuste virtualStoreType, que deja explícita la elección entre un almacén virtual de dependencias local al proyecto o uno compartido a nivel de toda la máquina —una distinción que hasta ahora dependía de una bandera booleana poco descriptiva—, y corrige el manejo de rutas con caracteres no ASCII, URLs de paquetes con caracteres codificados en porcentaje y el consumo de memoria en paquetes comprimidos de más de 16 MiB. Esta sección documentó, el 15 y el 16 de agosto, las candidatas 5 y 6 de la misma versión 12, centradas en instalar otros gestores de paquetes con firma verificada; la de hoy no toca esa función y en cambio se concentra en el sistema de configuración de registros, sin que el registro de cambios consultado confirme todavía una fecha de disponibilidad general. La información de esta nota proviene únicamente del registro de lanzamientos oficial de pnpm en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de pnpm, pero el gestor de paquetes gana terreno entre equipos locales que manejan monorepos de JavaScript y TypeScript, a los que conviene tratar esta séptima candidata como material de prueba y revisar si su configuración actual de registros privados se apoya en el comportamiento que la nueva versión está por cambiar.
Entre una caída global de GitHub que duró horas y nueve fallas de seguridad que Redis corrigió de un solo lanzamiento, esta edición documenta cinco desarrollos recientes en el ecosistema de programación.
Esta edición documentó cinco desarrollos entre el 17 y el 18 de agosto de 2026: la interrupción global de GitHub, que afectó su sitio, la API, Actions y Copilot durante horas el 17 de agosto; la versión 8.10.1 de Redis, que corrigió nueve vulnerabilidades de seguridad de una sola vez; las versiones 1.20260817.1 y 1.20260818.1 de Cloudflare workerd, que suman ocho lanzamientos consecutivos con correcciones de fugas de memoria; dos canarios más de Next.js centrados en el motor de caché persistente de Turbopack; y la séptima candidata de pnpm 12, que rediseña la configuración de registros de paquetes. El hilo que domina la jornada es la fragilidad de la infraestructura compartida: una sola interrupción en GitHub bastó para golpear a la vez el control de versiones, la integración continua y el asistente de código de buena parte de la industria del software, mientras Redis recordaba, con nueve fallas corregidas en un solo parche —varias presentes desde hace tiempo en siete ramas distintas—, que la carga de datos desde archivos RDB sigue siendo una superficie de ataque activa. Cloudflare Workers y su motor workerd continúan como personaje de la semana en esta sección: ocho versiones consecutivas desde el 12 de agosto, la más reciente centrada en cerrar fugas de memoria en el recolector de basura, confirman que la cadencia casi diaria de publicación se sostiene incluso cuando el contenido de cada versión es una corrección interna, no una función nueva. Para equipos de desarrollo en Costa Rica, la lista de hoy suma tareas concretas: revisar si algún servicio propio depende de GitHub Actions para desplegar y documentar un plan de contingencia ante una caída similar; aplicar el parche 8.10.1 de Redis o la versión de mantenimiento correspondiente a su rama; y tratar tanto los canarios de Next.js como la séptima candidata de pnpm 12 como material de prueba, no de producción.