Incidente en Issues y Webhooks – Resuelto

 (githubstatus.com)
1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • GitHub investigó una degradación del rendimiento en Issues y Webhooks y luego cambió el estado del incidente a resuelto el 4 de mayo de 2026 a las 16:40 UTC
  • Este incidente afectó a Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages y Codespaces
  • A las 15:45 UTC comenzó la investigación sobre la degradación del rendimiento en Issues y Webhooks, y a las 15:48 UTC se amplió a la investigación de mayor latencia y timeouts en varios servicios de GitHub
  • Desde las 16:25 UTC, Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces y Webhooks fueron restableciéndose o mitigándose de forma escalonada
  • GitHub indicó que la latencia en toda la plataforma volvió a la normalidad y que seguirá trabajando en la prevención de recurrencias y en el análisis de causa raíz para compartirlo cuando esté listo

Resumen del incidente

  • GitHub anunció que el incidente quedó resuelto tras investigar reportes de degradación del rendimiento en Issues y Webhooks
  • El incidente afectó a Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages y Codespaces
  • GitHub agradeció a los usuarios por su paciencia mientras atendían el problema y señaló que compartirá un análisis de causa raíz detallado en cuanto esté preparado

Evolución

  • Inicio de la investigación

    • El 4 de mayo de 2026 a las 15:45 UTC se anunció que estaban investigando reportes de degradación del rendimiento en Issues y Webhooks
    • A las 15:48 UTC se amplió el aviso para indicar que también estaban investigando mayor latencia y timeouts en varios servicios de GitHub

  • Ampliación de los servicios afectados

    • A las 15:48 UTC se informó que Git Operations estaba experimentando degradación del rendimiento
    • A las 15:50 UTC se informó que Packages estaba experimentando degradación del rendimiento
    • A las 15:51 UTC se informó que Actions estaba experimentando degradación del rendimiento
    • A las 15:51 UTC se informó que Pull Requests estaba experimentando una reducción de disponibilidad
    • A las 15:56 UTC se informó que Pull Requests estaba experimentando degradación del rendimiento
    • A las 16:05 UTC se informó que Codespaces estaba experimentando degradación del rendimiento
    • A las 16:06 UTC se informó que Pages estaba experimentando degradación del rendimiento

  • Restablecimiento y mitigación

    • A las 16:25 UTC se informó que Git Operations operaba con normalidad
    • A las 16:28 UTC se informó que Actions y Packages operaban con normalidad
    • A las 16:29 UTC se informó que Pages operaba con normalidad
    • A las 16:29 UTC se informó que la latencia en toda la plataforma volvió a la normalidad y que seguían investigando la causa raíz y trabajando para prevenir recurrencias
    • A las 16:32 UTC se informó que Pull Requests operaba con normalidad
    • A las 16:34 UTC se informó que la degradación del rendimiento que afectó a Issues fue mitigada y que seguían monitoreando para confirmar la estabilidad
    • A las 16:35 UTC se informó que la degradación del rendimiento que afectó a Codespaces fue mitigada y que seguían monitoreando para confirmar la estabilidad
    • A las 16:35 UTC se informó que Webhooks operaba con normalidad

  • Resolución

    • A las 16:36 UTC se informó que la degradación del rendimiento había sido mitigada y que seguían monitoreando para confirmar la estabilidad
    • A las 16:40 UTC el incidente pasó al estado de resuelto
    • El análisis de causa raíz detallado se compartirá tan pronto como esté disponible

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Comentarios de Hacker News

  • GitHub publicó cifras sorprendentes de aumento de uso diciendo que se debe al incremento de la programación con agentes, pero al final en algún momento parece que tendrán que cambiar los límites de velocidad, reducir el uso del plan gratuito o encontrar otra forma de bajar la carga
    Se ve claro que la infraestructura no está pudiendo seguir este ritmo de crecimiento, y es poco probable que GitHub siga absorbiendo tal cual el aumento de costos. Da curiosidad ver qué va a pasar con GitHub en adelante

    • El 3 de abril, la COO de GitHub ya había dicho que la actividad en la plataforma estaba aumentando con fuerza
      En 2025 hubo 1,000 millones de commits, pero ahora van en 275 millones por semana, así que incluso con un crecimiento lineal eso daría un ritmo de 14,000 millones este año. GitHub Actions también pasó de 500 millones de minutos por semana en 2023 a 1,000 millones por semana en 2025, y esta semana ya llegó a 2,100 millones de minutos
      Dijo que están empujando con mucha fuerza para agregar CPU, escalar servicios y reforzar las funciones principales de GitHub
      https://x.com/kdaigle/status/2040164759836778878
      También hay una entrada reciente del blog sobre disponibilidad: https://github.blog/news-insights/company-news/an-update-on-...
      Los problemas de escalabilidad que están enfrentando los ingenieros de GitHub realmente no se ven nada sencillos
    • Viéndolo durante décadas, ha habido sistemas que hacen cada tarea barata y sistemas que se esfuerzan por escalar horizontalmente, y muchas veces los primeros terminan ganando por mucho a los segundos
      Por ejemplo, GitHub parece haber implementado la página /pulls de un repositorio como si fuera una consulta de búsqueda; la pista era la caja de búsqueda precargada, y quedó casi confirmado la semana pasada cuando durante una caída del backend de búsqueda dejaron de cargar los pull requests. Pero también podría haberse implementado con una llamada normal a la API que solo trajera los pull requests abiertos, esa API existe y no se cayó
      Si GitHub se enfocara en encontrar y optimizar el 95% superior de tareas como la carga de páginas y las llamadas API asociadas, parecería posible reducir la carga del backend en más de 5 veces solo simplificando
      El visor de diff también parece tener bastante margen de mejora. Gran parte de la ineficiencia horrible seguramente está del lado del frontend y no cargando directamente el backend, pero las funciones normales de línea de comandos de git son muy rápidas
    • Parece que ya se está acercando al punto de no retorno. A menos que separen la infraestructura gratuita de la de pago, no sé si podrán salir del hoyo que ellos mismos cavaron solo con escalado horizontal
      Así como hace falta que alguien sea 10 veces mejor para lograr que cambies de producto, si el producto actual se vuelve 10 veces peor, la competencia recibe gratis una ventaja de 10 veces aunque no haga nada
    • Una semana después de que GitHub publicara eso en su blog, y un día después de que ejecutivos de GitHub lo repitieran en comentarios de HN, se instaló casi de inmediato la idea de sentido común de que la caída de confiabilidad desde 2019 no se debía a la integración con Microsoft de 2019, sino a algo que recién apareció en 2023
      Las relaciones públicas funcionan. La conclusión terminó siendo que GitHub falla porque le va demasiado bien
    • Siempre he estado totalmente a favor de reasignar toda la capacidad de servidores de LinkedIn a GitHub

  • Según https://mrshu.github.io/github-statuses, la disponibilidad de GitHub en los últimos 90 días es de 84.92%
    No entiendo cómo eso podría considerarse aceptable aunque sea un poco

    • Ese sitio parece sobrecontar el tiempo de caída. Incluso filtrando solo incidentes major y critical dignos de llegar a la portada de HN, sigue siendo malo, pero no tan malo como 84.92%
      https://isgithubcooked.com/?severities=major.critical
    • No es aceptable. Últimamente pasan muchas cosas inaceptables y parece que todos las aceptan como si nada
    • Ni siquiera están alcanzando dos ochos, ya ni hablar de three nines

  • Ya llegó a un nivel de rendimiento difícil de aceptar. No hay semana en que GitHub no interrumpa el trabajo

    • Los agentes de IA de hecho cambiaron las características de escalabilidad de prácticamente todo internet
      Antes GitHub podía asumir que un número limitado de personas usaba la plataforma de formas humanas y con patrones observables, y seguramente escalaba y optimizaba los cuellos de botella de UI/UX según esos patrones
      Pero ahora todo el mundo tiene uno o varios bots corriendo 24/7, y eso está sobrecargando muchos servicios. Más todavía en servicios que hoy están tan centrados en agentes como GitHub
    • Desde hace meses ya estaba en un nivel inaceptable, y ahora ya está cerca del punto de buscar activamente alternativas
    • Ya no es cuestión de alegrarse si pasa una semana sin incidentes; habría que alegrarse si pasa un solo día
      Ya perdí la cuenta de cuántas veces se repite esto cada lunes por la mañana, hora del Pacífico
    • En Europa está mucho mejor. Yo terminé de trabajar unas horas antes de que empezara este incidente, y no recuerdo grandes caídas que me hayan obligado a parar el trabajo en los últimos meses
      Sí hubo una vez reciente en la noche en que me afectó cuando quería avanzar en un proyecto personal
    • Creo que el nivel inaceptable ya quedó muy atrás

  • Ahora ya estamos en el punto en que los posts de GitHub caído compiten cada semana en la portada de HN con un nuevo post exagerado sobre LLMs
    Estoy considerando mover todos mis proyectos personales a Codeberg. La estabilidad de GitHub es una razón, pero también me gusta que sea una alternativa no atada estrictamente a una gran empresa tecnológica

    • El spam de que Claude Code es casi magia era de lo peor, pero parece que por un rato quedó desplazado por los posts del estado de GitHub. Puede que ahora estemos en una fase más tranquila de publicidad de Claude
    • Y aun así la gente todavía no se cambia: ese es el problema de una plataforma dominante. Un poco de incomodidad e inercia basta para que nadie se vaya
      Incluso sin abuso monopólico, y aquí estoy hablando de Microsoft

  • Es gracioso que casi todo parezca degradado menos Copilot. El chiste prácticamente se escribe solo

    • Comparada con las funciones que están degradadas ahora, toda la funcionalidad de Copilot representa solo una parte de la utilidad
    • Copilot probablemente está completamente separado del lado de repositorios de GitHub, corriendo en una infraestructura totalmente distinta sin una fuerte dependencia del monolito en Rails

  • Es raro y un poco triste que ya sienta que estoy desarrollando un sexto sentido para detectar cuándo GitHub va a tener una caída
    Hace como una hora le di a “Resolve Conversation” en un pull request y falló varias veces; además el mensaje de error aparecía fuera de pantalla, abajo de la página, así que al principio no se veía. Cada pocas acciones tenía que recargar la página para que el servidor reflejara el nuevo estado
    Le dije a un colega que parecía que GitHub tenía algún problema en otro servicio y que eso se había propagado a los comentarios de PR, y que podía terminar convirtiéndose en una caída más grande

    • Acabo de ver exactamente la misma señal en comentarios de revisión de PR. Revisé la página de estado y estaba en verde; supuse que no duraría mucho, y así fue

  • Hay que recortar el plan gratuito
    En los últimos 2.5 meses hice 4,000 commits, y eso solo en main. Además subo montones de artefactos todos los días para pruebas de regresión
    El costo es 0 dólares

    • Sinceramente odio el plan gratuito de este tipo de productos SaaS
      Hace tiempo, cuando Google ofreció por muy poco tiempo un servicio de Git de pago por uso en GCP, yo usaba eso. Porque quería que lo mío fuera realmente mío. Pero todos usaban GitHub “gratis”, y como tantos otros servicios de Google, ese servicio parece haber sido cerrado
      Así que ahora uso GitHub gratis, pero preferiría pagarle a un gran proveedor de nube por el repositorio y por el uso
    • Si hacen eso, los proyectos de código abierto que todavía no se han ido van a migrar
    • Viéndolo solo del lado del repositorio, eso se acerca a como dos minutos de uso de CPU
    • GitHub debería cobrar un impuesto al código basura. ¿Coescrito con Claude? Paga. ¿Muchos em dash en los comentarios? Paga. ¿Se escribió mucho código en poco tiempo? Paga

  • Esto ya está llegando a un nivel verdaderamente ridículo. A veces se ignora la página de estado cuando marca que incluso Copilot “está caído”, pero hay que ver que la disponibilidad de pull requests es de 95.5%, todavía peor que el 96.4% de Copilot
    No sé cómo esperan que uno deje un comentario de “LGTM” si ni siquiera puede entrar al PR

  • Al menos la gente está aprendiendo a usar el comando git remote