¿Cron job y crontab son lo mismo?

No. El crontab es el archivo (y el comando) donde listas las programaciones. Un cron job es cada tarea programada dentro de él. Cron es el programa que lee el crontab y dispara los jobs.

¿Cómo ejecutar una tarea cada 5 minutos?

Usa `*/5 * * * *`. El paso `*/5` en el campo de minutos dispara en los minutos 0, 5, 10 y así sucesivamente, cada hora.

¿Qué significa 0 0 * * *?

Se ejecuta todos los días a medianoche, en la zona horaria con la que está configurado cron. Minuto 0, hora 0 y los demás campos libres.

¿Se puede ejecutar cron en intervalos de segundos?

El cron de Unix no, su unidad mínima es el minuto. Librerías de aplicación como node-cron aceptan un campo opcional de segundos al inicio de la expresión.

Qué es un cron job y cómo programar tareas

Cron es el programador de tareas clásico de los sistemas Unix y Linux. Tú le dices cuándo debe ejecutarse algo y qué ejecutar, y él lanza el comando solo, sin que nadie pulse un botón. Cada tarea programada se llama cron job.

Casi todo proyecto termina necesitándolo: limpiar archivos temporales cada madrugada, enviar un resumen diario, renovar un token, sincronizar datos con otra API. El concepto es sencillo. Lo difícil es acertar con la expresión de horario y recordar los detalles que hacen que el job corra a la hora equivocada.

¿Cómo es una expresión cron?#

Una expresión tiene cinco campos separados por espacios, seguidos del comando:

text

┌───────── minuto (0-59)
│ ┌─────── hora (0-23)
│ │ ┌───── día del mes (1-31)
│ │ │ ┌─── mes (1-12)
│ │ │ │ ┌─ día de la semana (0-6, domingo = 0)
│ │ │ │ │
* * * * *  comando a ejecutar

Cada campo acepta un número, una lista (1,15), un rango (1-5) o *, que significa "todos los valores". Esos elementos forman parte del estándar POSIX. El cron de Linux añade pasos (*/5), nombres de meses y días (mon, jan) y acepta 7 como domingo. Los atajos @daily, @hourly, @weekly, @monthly, @yearly y @reboot también son extensiones de Linux, no de POSIX.

¿Qué expresiones vas a usar más?#

Expresión	Cuándo se ejecuta
`* * * * *`	Cada minuto
`/5 * * *`	Cada 5 minutos
`0 * * * *`	Al inicio de cada hora
`0 3 * * *`	Todos los días a las 03:00
`30 8 * * 1-5`	De lunes a viernes a las 08:30
`0 0 1 * *`	El primer día de cada mes, a medianoche
`0 9 * * mon`	Todos los lunes a las 09:00
`0 0 1 1 *`	Una vez al año, el 1 de enero (igual a `@yearly`)

Si dudas, lee la expresión en voz alta, campo por campo: "minuto 30, hora 8, cualquier día del mes, cualquier mes, de lunes a viernes".

¿Cómo instalar un cron job en Linux?#

Abre tu crontab con crontab -e y añade una línea por tarea. Esta limpia archivos temporales todos los días a las 03:00 y guarda la salida en un log:

cron

0 3 * * * /usr/local/bin/limpiar-temporales.sh >> /var/log/limpieza.log 2>&1

Lista lo programado con crontab -l. Tres cuidados evitan la mayoría de los problemas:

Usa rutas absolutas. Cron ejecuta el comando con /bin/sh en un entorno mínimo, sin tu perfil de shell. Un node o un script que funciona en tu terminal puede no encontrarse.
Redirige la salida. Por defecto, cron intenta enviar la salida del job por correo al dueño del crontab. Sin correo configurado, la salida (y el error) suele perderse. Escribe en un archivo de log, como arriba.
Da permiso de ejecución al script (chmod +x).

¿Cuáles son las trampas más comunes?#

Un paso no es un intervalo continuo. El paso solo vale dentro de su propio campo. */35 * * * * se ejecuta en los minutos 0 y 35 de cada hora, no cada 35 minutos. Para intervalos que no dividen 60 o 24, cron puro no sirve: programa una tarea más frecuente que decida si debe actuar.

Día del mes y día de la semana forman un "O". Cuando ambos campos están rellenados, el job corre si cualquiera de los dos coincide. 30 4 1,15 * 5 se ejecuta a las 04:30 los días 1 y 15 y también todos los viernes. Quien espera un "Y" se lleva una sorpresa. Si necesitas "todos los viernes entre el día 1 y el 7", programa todos los viernes y comprueba la fecha dentro del script.

Zona horaria. Cron usa la zona del servidor, que en entornos de nube suele ser UTC. Allí, 0 3 * * * corre a las 03:00 UTC, no a las 03:00 de tu ciudad. Implementaciones como cronie admiten la variable CRON_TZ en el crontab, y las librerías de aplicación tienen una opción de zona horaria. Declara la zona de forma explícita siempre que importe la hora local.

Ejecuciones solapadas. Si una ejecución tarda más que el intervalo, la siguiente empieza encima. Protege las tareas largas con un archivo de bloqueo o una bandera de "ya está corriendo".

Cambio de hora. En zonas con horario de verano, una hora puede saltarse o repetirse. cronie lo compensa para los jobs de hora fija, pero no todos los programadores lo hacen, y el job de esa hora puede correr dos veces o ninguna. Prefiere UTC para tareas críticas.

¿Cómo programar tareas dentro de una aplicación Node.js?#

No todo entorno te deja editar un crontab. En hosting de aplicaciones, lo habitual es programar dentro del propio proceso con una librería. Una de las más usadas en Node.js es node-cron:

bash

npm install node-cron

// index.js (necesita "type": "module" en package.json)
import cron from "node-cron";

const tarea = cron.schedule(
  "0 3 * * *",
  () => {
    console.log("Rutina de las 03:00 en Ciudad de México:", new Date().toISOString());
    // limpiar archivos, sincronizar datos, enviar un informe...
  },
  { timezone: "America/Mexico_City" },
);

// tarea.stop() pausa y tarea.start() reanuda

La expresión es la misma de cinco campos. node-cron también acepta un campo opcional de segundos al inicio (*/10 * * * * * dispara cada 10 segundos), algo que el cron de Unix no hace.

Esto exige que el proceso permanezca siempre encendido: si la aplicación está detenida o dormida a la hora marcada, el job no corre. Por eso, un programador dentro del proceso necesita un hosting que mantenga el contenedor activo, sin suspensión por inactividad. Si tienes varias instancias de la misma aplicación, cada una dispara el job, así que ejecuta el programador en una sola. Guarda claves y URLs en variables de entorno, nunca en el código.

¿Cuándo cron no es la mejor herramienta?#

Cron es excelente para rutinas guiadas por el reloj. Es débil cuando la tarea depende de un evento ("cuando el usuario pague, envía el recibo"), cuando necesita reintentos automáticos tras un fallo, o cuando el trabajo es pesado y debe repartirse entre varios procesos. Colas y workers encajan mejor ahí. Para la base, mira cómo alojar una aplicación Node.js o un script en Python que se mantiene en ejecución todo el tiempo.

Cómo hacerlo en Square Cloud#

Un programador dentro del proceso depende de una sola cosa: que el proceso esté vivo a la hora programada. En Square Cloud el contenedor está siempre encendido, sin modo de suspensión y sin regla de inactividad, así que el node-cron del ejemplo dispara a tiempo aunque nadie visite la aplicación. Con el reinicio automático, activado por defecto en el deploy desde el panel, el proceso vuelve solo cuando termina con error.

En la práctica:

Escribe el job con la librería y pasa la zona en la opción timezone, en lugar de depender del reloj del servidor.
Haz el deploy con un ZIP en el panel, la CLI o GitHub. El archivo squarecloud.app es opcional: el panel lo genera con runtime, memoria y archivo principal.
Guarda las claves y URLs del job como variables de entorno de la aplicación y sigue cada ejecución en los logs en tiempo real.

Un programador independiente corre como aplicación en segundo plano, sin subdominio. Una app pequeña con node-cron cabe en 256 MB, el mínimo para ese tipo de aplicación, y el Hobby empieza en R$12,49 al mes con 1 GB de RAM compartida entre tus aplicaciones. Si tu API reparte su dominio entre varias aplicaciones con load balancing, cada copia dispara el job: deja el programador en una sola aplicación. Consulta las opciones para hospedar APIs y jobs en hosting de APIs y el runtime en Node.js.