El cron scheduler gratis escondido en cada repo de GitHub
Si alguna vez configuraste GitHub Actions para correr tests al hacer push, ya tenés un programador de tareas gratis y no lo sabías. El trigger schedule corre cron sin que provisiones ni pagues servidores: ilimitado en repos públicos y con 2.000 minutos mensuales en privados, según la documentación oficial de GitHub.
El GitHub Actions scheduler gratuito es la funcionalidad on: schedule dentro de un workflow de GitHub Actions que ejecuta tareas según sintaxis cron estándar, sobre infraestructura administrada por GitHub. Sirve para backups, reportes, limpiezas y chequeos periódicos sin VPS propio. Es de GitHub (Microsoft) y viene incluido en cada repositorio que tengas, sea público o privado.
En 30 segundos
- Gratis de verdad: ilimitado en repos públicos, 2.000 minutos/mes en privados (plan Free).
- No es puntual: el scheduler es best-effort, con demoras variables, sobre todo en horarios redondos como :00.
- Intervalo mínimo: 5 minutos entre ejecuciones programadas; el job individual corta a las 6 horas.
- Se apaga solo: tras 60 días sin commits en el repo, GitHub deshabilita los workflows programados.
- No te avisa si falla: tenés que armar el monitoreo aparte (Slack, email o un “dead man’s switch”).
¿Qué es el GitHub Actions scheduler gratuito y cómo funciona?
GitHub Actions es el sistema de CI/CD integrado en GitHub. La mayoría lo usa para una sola cosa: correr los tests y desplegar al hacer push. Pero adentro de la misma feature hay un disparador que casi nadie toca.
Ese disparador es on: schedule, y funciona con sintaxis cron de toda la vida. Lo contó Aaron Philip en dev.to el 18 de junio de 2026: armó un “dead man’s switch” a costo cero para detectar fallas silenciosas. La idea detrás es simple. Tenés un script que tiene que correr solo, calladito, y un día lo necesitás y resulta que no se ejecutó en dos semanas. Sin error, sin mail, sin la X roja en ningún lado. Se frenó y nadie en tu mundo se enteró.
Un workflow mínimo se ve así:
on:
schedule:
- cron: '0 14 * * *' # todos los días a las 14:00 UTC
jobs:
tarea:
runs-on: ubuntu-latest
steps:
- run: echo "corriendo la tarea programada"Eso sí: el cron de GitHub se interpreta en UTC. No tiene zona horaria configurable, así que tenés que hacer la cuenta vos. Argentina está en UTC-3, entonces las 14:00 UTC son las 11:00 de acá.
¿Cuál es el máximo de minutos gratis en GitHub Actions?
Acá viene la parte que confunde a todos. En repos públicos los minutos son ilimitados. En repos privados con plan Free tenés 2.000 minutos por mes incluidos, y cada job tiene un timeout máximo de 6 horas según la guía de timeouts de Graphite.
La cuenta es fácil de hacer mal. Si un job tarda 5 minutos y corre cada hora, son 24 corridas por día, 120 minutos diarios, 3.600 al mes. Te pasaste del límite con una sola tarea. La trampa es asumir que “5 minutos no es nada”. Lo explicamos a fondo en parte de tu estrategia CI/CD.
| Tarea | Frecuencia | Duración | Minutos/mes | ¿Entra en Free? |
|---|---|---|---|---|
| Backup diario | 1 vez/día | 5 min | ~150 | Sí |
| Reporte por email | 1 vez/día | 3 min | ~90 | Sí |
| Limpieza semanal | 1 vez/semana | 2 min | ~8 | Sí |
| Chequeo horario | 24 veces/día | 5 min | ~3.600 | No (en privado) |
Conclusión práctica: para tareas diarias o semanales en un repo privado, te sobra. Para algo que corre cada pocos minutos, mejor un repo público o pasarte a otra cosa.
¿Cómo configurar un cron job en GitHub Actions paso a paso?
La sintaxis cron tiene cinco campos: minuto, hora, día del mes, mes y día de la semana. Si nunca la usaste, Crontab.guru te valida la expresión en tiempo real antes de que la pegues en el YAML.
0 14 * * *: todos los días a las 14:00 UTC.0 0 * * 0: cada domingo a medianoche UTC.*/15 * * * *: cada 15 minutos (recordá el piso de 5).
Un consejo que ahorra dolores de cabeza: agregá workflow_dispatch junto al schedule. Eso te habilita un botón para correr el workflow a mano desde la pestaña Actions, sin esperar al cron. Probás que funciona y recién después lo dejás programado.
on:
schedule:
- cron: '17 3 * * *' # 3:17 UTC, evitá horarios redondos
workflow_dispatch: # botón manual para probar¿Por qué tu cron job de GitHub Actions se ejecuta retrasado?
Esta es la queja número uno, y aparece en las discusiones de la comunidad de GitHub. La respuesta corta: el scheduler es best-effort, no garantizado. GitHub no te promete ejecutar exacto a la hora que pusiste.
¿Por qué pasa? Hay una cola global compartida por todos los workflows programados del planeta. Cuando muchísima gente agenda tareas para el mismo segundo (las 0:00, las 12:00, top of hour), la cola se satura y tu job espera. Las demoras se concentran en los horarios redondos.
El workaround es de manual: no uses minutos redondos. En vez de 0 * * * * poné 23 * * * * o 17 3 * * *. Le escapás a la hora pico de la cola y tu tarea arranca más cerca de lo previsto. Sobre eso hablamos en si ya usás GitHub Actions.
Hay otra causa de que directamente no corra: si el repo no recibe commits durante 60 días, GitHub desactiva los workflows programados de forma automática. ¿Tu tarea dejó de ejecutarse sin razón aparente? Fijate la fecha del último commit antes de revisar el YAML.
Casos de uso: backup, reportes diarios y limpiezas
Backup diario de base de datos
Un dump de PostgreSQL con 0 0 * * * tarda entre 5 y 10 minutos según el tamaño, y se va a 150-300 minutos al mes. Entra cómodo en el Free tier. Si la base es de un sitio que tenés alojado, conviene que el backup viva cerca del hosting. Para infraestructura y dominios en Argentina, donweb.com te resuelve el alojamiento y vos dejás el cron de GitHub como copia externa de seguridad.
Reporte diario por email
Un script Node.js con Nodemailer que arma un resumen y lo manda a las 0 14 * * * corre en unos 3 minutos, 90 al mes. Space Jelly tiene una guía de cómo conectarlo con Gmail. Es uno de los usos más comunes y baratos.
Limpieza semanal y security scan
Borrar artifacts o cache viejos un domingo (0 0 * * 0) gasta 2 minutos, 8 al mes. Y podés sumar un scan de dependencias diario para detectar vulnerabilidades. Todo eso, junto, sigue entrando en los 2.000 minutos gratis sin despeinarte.
¿Cómo monitorear tus tareas y alertarte si fallan?
Acá está el agujero grande: GitHub Actions no te avisa por defecto cuando un workflow programado falla. Te enterás cuando alguien pregunta dónde está el reporte o, peor, cuando necesitás el backup y no está. Tres formas de taparlo:
- Dead man’s switch: en vez de alertar cuando falla, hacés un ping cada vez que tiene éxito. Si el servicio externo no recibe el ping dentro de un período de gracia (por ejemplo 25 horas para una tarea diaria), te avisa. Captura la falla silenciosa, que es la peor.
- Notify Slack Action: agregás un step con
if: failure()en el YAML y un webhook. La acción de ravsamhq te tira el mensaje al canal apenas algo se rompe. - Email con Nodemailer: mismo patrón, un step condicional que dispara un mail si el job falló.
GitHub Actions vs AWS Lambda vs Google Cloud Scheduler
¿Cuál te conviene? Depende de si priorizás “gratis y simple” o “ejecución garantizada”. La tabla resume las diferencias reales: Te puede servir nuestra cobertura de para publicación programada multiidioma.
| Opción | Free tier | Puntualidad | Mejor para |
|---|---|---|---|
| GitHub Actions | Ilimitado público / 2.000 min privado | Best-effort, con demoras | Repos públicos, tareas no críticas en horario |
| AWS Lambda | 1M requests + 400.000 GB-seg/mes (permanente) | Buena, hay cold starts | Event-driven, alto volumen |
| Google Cloud Scheduler | 3 jobs/mes gratis, luego USD 0,10/job/mes | Alta, muy preciso | Pocas tareas que necesitan puntualidad |
| Vercel Crons | Incluido con Vercel | Buena | Proyectos Next.js ya en Vercel |
El resumen honesto: GitHub gana en “gratis más simple” para repos públicos. Pierde cuando necesitás que la tarea corra exacto a las 9:00 sin excusas. Para eso, Google Cloud Scheduler es más confiable aunque te cobre centavos.
Qué está confirmado y qué no
- Confirmado: minutos ilimitados en públicos y 2.000/mes en privados, según la documentación de GitHub.
- Confirmado: intervalo mínimo de 5 minutos y timeout máximo de 6 horas por job.
- Confirmado: desactivación automática tras 60 días sin commits.
- No garantizado: la hora exacta de ejecución. GitHub lo declara como best-effort, y las demoras varían según la carga global de la cola.
Errores comunes
- Programar en horario local: el cron corre en UTC, no en tu zona. Si querés las 9:00 de Argentina, poné
0 12 * * *(UTC-3). Olvidarte de esto te corre la tarea tres horas desfasada. - Usar minutos redondos: agendar a las
0 * * * *te mete de lleno en la hora pico de la cola global. Cambiá a un minuto cualquiera y reducís la demora. - Asumir que vas a saber si falla: sin monitoreo externo, una falla es invisible. Armá el dead man’s switch o la alerta a Slack antes de confiarle algo importante.
- No probar con workflow_dispatch: esperar al cron para ver si tu YAML funciona es perder horas. Sumá el botón manual y testealo en segundos.
Preguntas Frecuentes
¿Cuál es el máximo de minutos gratis en GitHub Actions?
En repos públicos los minutos son ilimitados. En repos privados con plan Free tenés 2.000 minutos por mes. Cada job individual corta a las 6 horas de ejecución.
¿Por qué mi cron job se ejecuta retrasado?
Porque el scheduler de GitHub es best-effort y usa una cola global compartida. Las demoras se concentran en los horarios redondos como :00. Evitá los minutos redondos en tu expresión cron para reducir la espera.
¿GitHub Actions tiene zona horaria configurable?
No. Todas las expresiones cron se interpretan en UTC y no hay opción de timezone. Para Argentina (UTC-3) tenés que sumar 3 horas a tu hora local al escribir el cron. Esto se conecta con lo que analizamos en ejecutar jobs locales automatizados.
¿Puedo hacer un backup diario de mi base de datos gratis?
Sí. Un backup diario de PostgreSQL tarda 5-10 minutos y consume 150-300 minutos al mes, dentro del Free tier. Solo necesitás un step que corra el dump y suba el archivo a un almacenamiento externo.
¿Cómo recibo alertas si falla mi tarea programada?
GitHub no alerta por defecto. Agregá un step con if: failure() y un webhook de Slack, o un dead man’s switch que te avise si no recibe un ping de éxito dentro de un período de gracia. Sin monitoreo externo, las fallas pasan desapercibidas.
Conclusión
Tenés un programador de tareas gratis en cada repo que poseés y probablemente nunca lo usaste para nada más que correr tests. Para backups, reportes y limpiezas que toleran unos minutos de demora, el GitHub Actions scheduler gratuito es difícil de superar: cero infraestructura, cero costo en públicos, sintaxis cron de toda la vida.
El “pero” es serio. No es puntual y no te avisa si falla. Así que la regla práctica es esta: usalo para todo lo que no sea crítico al minuto, evitá horarios redondos, hacé la cuenta de minutos antes de agendar algo frecuente, y montá el monitoreo externo antes de confiarle un backup que de verdad importe. Empezá por una tarea chica esta semana y le agregás el dead man’s switch arriba.
