GitHub Actions: startup_failure en todos los workflows

Haces push a main y el despliegue no se actualiza. En la pestaña Actions, todas las ejecuciones de todos los workflows, en todas las ramas, aparecen como fallidas sin haber ejecutado ni un solo paso. Con la CLI de GitHub, el campo conclusion de esas ejecuciones vale startup_failure:

gh run list --limit 10 --json databaseId,workflowName,headBranch,event,status,conclusion

El YAML no ha cambiado y es válido, así que reintentar las ejecuciones tampoco cambia el resultado: la causa no está en el archivo. Como tampoco hay un error en tu código, es fácil tardar días en notar que el despliegue dejó de actualizarse.

Este artículo explica qué suele estar detrás de este patrón (todos los workflows fallan al arrancar), con una causa que a veces se pasa por alto: la facturación de la cuenta. También cómo diagnosticarlo y cómo recuperar el despliegue.

Por qué pasa

La documentación de GitHub no define startup_failure en una página propia: no aparece en la referencia de la API de ejecuciones de workflows ni en la guía de solución de problemas de workflows. La CLI de GitHub sí lo incluye entre los valores que acepta gh run list --status. Por los casos reportados en la comunidad, designa ejecuciones que fallaron al arrancar, antes de ejecutar tus pasos. No es una lista completa de causas, pero estas son las que se pueden sustentar:

Un problema de facturación o de límite de gasto de la cuenta. La guía oficial de solución de problemas indica que definir un presupuesto (budget) de Actions puede desbloquear de inmediato los workflows que fallan por errores de facturación o de almacenamiento. La documentación de facturación añade que, sin un método de pago válido, el uso se bloquea cuando se agota la cuota incluida. Según la documentación de presupuestos, si se agota uno que tiene activada la opción de detener el uso, se bloquea el uso adicional (en su ejemplo, los runners alojados por GitHub, hasta el siguiente ciclo de facturación o hasta aumentar el presupuesto). Y si un pago vence por problemas de facturación, las funciones de pago de la cuenta quedan bloqueadas. En hilos de la comunidad de GitHub se reporta, en la página de la ejecución, un mensaje que dice que el job no se inició porque fallaron pagos recientes o porque hay que aumentar el límite de gasto.
Un archivo de workflow con errores de validación. Es una causa reportada en la comunidad (YAML o claves inválidas, por ejemplo). Como el defecto está en un archivo concreto, afecta a ese workflow y no a todos los demás.

La pista para distinguirlos es el alcance. Si falla un único workflow, revisa su archivo. Si fallan todos, incluidos los que no tocas desde hace meses y los de ramas antiguas, el problema está en la cuenta y no en el YAML.

Solución

Confirma el alcance con la CLI. Lista las ejecuciones recientes y filtra por el estado:
```
gh run list --limit 20 --json databaseId,workflowName,headBranch,event,status,conclusion
gh run list --status startup_failure --limit 20
```
Si todos los workflows y todas las ramas aparecen en startup_failure, sigue con el paso 2.
Abre una ejecución afectada y lee el mensaje. Desde la CLI:
```
gh run view ID_DE_EJECUCION --web
```
También puedes abrirla desde la pestaña Actions. Si el mensaje habla de pagos fallidos o de límite de gasto, pasa al paso 3.
Revisa la facturación de la cuenta. En una cuenta personal, abre github.com/settings/billing; en una organización, entra en su página Billing & Licensing. Comprueba lo siguiente:
- Método de pago: que no haya vencido y que el último cargo no se haya rechazado. Según la documentación sobre tarjetas rechazadas, tras un cargo rechazado GitHub envía un correo con el motivo y da unos días para resolverlo antes de volver a intentar el cobro.
- Restricciones del banco: esa misma página señala que algunos bancos internacionales restringen las transacciones internacionales, de comercio electrónico y recurrentes automáticas. Si el cargo falla sin otra explicación, consulta con tu banco.
- Presupuestos: en Budgets and alerts, mira si hay un presupuesto de Actions con la opción de detener el uso al alcanzar el límite.
- Cuenta bloqueada: si la cuenta quedó bloqueada por un pago vencido, actualiza el método de pago. La documentación indica que se desbloquea sola cuando un pago se procesa con éxito, y que el proceso puede tardar hasta 24 horas.
Cuando el pago esté resuelto, lanza una ejecución nueva. Basta con un push o un pull request. Para poder lanzar el despliegue a mano, añade workflow_dispatch al disparador y fusiona el cambio en la rama predeterminada (según la documentación de ejecución manual, el workflow debe estar en esa rama para recibir el evento):
```
on:
  push:
    branches: [main]
  workflow_dispatch:
```
Después, desde la CLI (el nombre es el del workflow, o su archivo):
```
gh workflow run "Deploy" --ref main
```
Mientras el bloqueo siga activo, es de esperar que ni un push nuevo ni gh run rerun cambien el resultado, porque la causa no está en el workflow. Conviene añadir workflow_dispatch antes de necesitarlo.

Cómo verificar que quedó resuelto

gh run list --workflow "Deploy" --branch main --limit 5

Las ejecuciones nuevas deben terminar con conclusion igual a success en lugar de startup_failure. Después, comprueba el efecto real del despliegue: que el servicio sirve la versión nueva (por ejemplo, por el identificador del build o la fecha de reinicio de los contenedores), no solo que el workflow esté en verde. Si el bloqueo era de facturación y se corrigió, es lo esperable: el mismo workflow, sin cambios, vuelve a ejecutarse.

Variantes y errores relacionados

No se crea ninguna ejecución

Es otro síntoma, con otras causas. La guía de solución de problemas menciona que un workflow desactivado no responde a sus disparadores, que los filtros de rama, etiqueta o ruta pueden omitir la creación de la ejecución, que los workflows de pull_request no se ejecutan si el pull request tiene un conflicto de fusión, y que eventos como schedule solo se ejecutan desde la rama predeterminada.

Solo un workflow en `startup_failure`

Revisa su archivo: según los casos reportados en la comunidad, un error de validación puede hacer que la ejecución termine así. Abre la ejecución y lee el mensaje que muestra la página. Si no ayuda, prueba con un workflow mínimo en una rama de pruebas para ver si el fallo depende del archivo o de la cuenta.

Prevenir el siguiente bloqueo

La documentación de presupuestos describe alertas al 75 %, 90 % y 100 % del presupuesto, por correo y como aviso en GitHub, y la de facturación de Actions describe avisos por correo cuando el uso incluido llega al 90 % y al 100 %. Actívalas, y añade una notificación (correo o chat) cuando falle el workflow de despliegue, para no descubrir el problema días después.

Resumen

startup_failure en todos los workflows y ramas, con el YAML intacto, apunta a un problema de cuenta y no a tu código.
GitHub documenta que la facturación puede bloquear el uso de Actions: método de pago ausente o vencido, presupuesto agotado o cuenta bloqueada por un pago vencido.
Revisa github.com/settings/billing (o Billing & Licensing en una organización): método de pago, cargos rechazados y presupuestos.
Cuando se resuelva, lanza una ejecución nueva (push, pull request o gh workflow run con workflow_dispatch); un reintento no cambia la causa mientras siga el bloqueo.
Verifica con gh run list que la conclusión sea success y que el servicio sirva la versión nueva.

Tutoriales Técnicos

Buscar este blog