Cron vs systemd para Node.js: ¿cuál usar?

Cron y systemd son las dos herramientas principales para la gestión de procesos Node.js en servidores Linux, pero no son intercambiables: cron es ideal para tareas atómicas que se ejecutan en momentos puntuales (un script que publica a las 9am, un backup a medianoche), mientras que systemd es la opción correcta para procesos que necesitan estar activos de forma continua, mantener estado en memoria y reiniciarse solos si fallan.

¿Qué es cron y para qué sirve?

Cron es el planificador de tareas clásico de los sistemas Unix. Existe desde los años 70 y su modelo es simple: definís una expresión de tiempo, un comando, y listo. El sistema operativo arranca el proceso en el momento indicado, el proceso se ejecuta y termina.

Ponele que tenés un script que publica un artículo en dev.to a las 9am y otro que postea en LinkedIn a las 10am. Según el análisis publicado en dev.to en mayo de 2026, la configuración completa en el crontab del usuario es literalmente esto:

0 9 * * * bash /home/folken/work/cv/scripts/devto-cron.sh >> logs/devto-cron.log 2>&1
0 10 * * * /usr/bin/node /home/folken/work/cv/scripts/linkedin-cron.js >> logs/linkedin-cron.log 2>&1

El shell script carga variables de entorno desde un archivo .env, llama al script Node.js, el script lee la lista de artículos pendientes, llama a la API, actualiza el archivo y sale. Runtime total: unos pocos segundos. Si algo falla, el log tiene el error y el artículo queda en cola para el día siguiente. Eso es todo.

¿Por qué funciona bien acá? Porque la tarea es atómica. No necesita saber qué pasó ayer. No tiene que reaccionar a nada externo. No puede solaparse con sí misma. Un proceso arranca, hace su trabajo, muere. Eso es exactamente para lo que cron fue diseñado hace cincuenta años y todavía sirve.

¿Qué es systemd daemon y cuándo usarlo?

Un daemon es un proceso que corre en segundo plano de forma continua, sin terminal asociada, esperando hacer algo. El clásico ejemplo: un servidor web, una API REST, un sistema que monitorea una cola de trabajos. Relacionado: integración con pipelines CI/CD modernos.

systemd es el sistema de init moderno en la mayoría de las distribuciones Linux (Ubuntu, Debian, Fedora, Arch). Su trabajo principal es arrancar y gestionar servicios del sistema, pero también puede supervisar tus aplicaciones con el mismo mecanismo.

La diferencia crítica con cron: systemd mantiene el proceso vivo. Si tu daemon de Node.js se cae porque hubo una excepción no manejada, systemd lo reinicia. Si el servidor se reinicia, systemd lo vuelve a levantar. Los logs van a journald y podés consultarlos con journalctl -u tu-servicio junto con todos los demás logs del sistema. Y con cgroups podés limitarle memoria o CPU al proceso sin instalar nada extra.

El caso concreto del análisis de dev.to es un sistema de monitoreo que revisa una cola de trabajos cada 30 segundos, mantiene estado en memoria y reacciona a acciones de la interfaz de usuario en cuestión de segundos. Cron no puede hacer esto (tendría que arrancar cada 30 segundos y leer estado de disco cada vez). systemd sí.

Diferencias clave: Cron vs Systemd

Característica	Cron	Systemd daemon
Duración del proceso	Arranca y muere al terminar	Corre de forma continua
Estado en memoria	No (cada ejecución es nueva)	Sí, persiste entre ciclos
Reacción a eventos externos	No	Sí (sockets, señales, etc.)
Configuración	1-2 líneas en crontab	Archivo .service de ~15 líneas
Logs	Redirect manual a archivo	journald integrado
Reinicio automático ante fallo	No	Sí (Restart=on-failure)
Arranque con el sistema	Sí (siempre activo)	Sí (con systemctl enable)
Control de recursos	No	Sí (cgroups: CPU, memoria)
Complejidad inicial	Muy baja	Media

Lo que no queda claro en muchas comparaciones es esto: no están compitiendo por el mismo problema. Es como comparar un martillo con un destornillador. Si te encontrás debatiendo “cron o systemd” para tu caso de uso, la respuesta casi siempre es obvia si describís el proceso correctamente.

Gestión de procesos Node.js: cuándo elegir cron

Usá cron cuando tu script Node.js cumpla con estas condiciones: arranca, hace algo puntual, y termina. Si el proceso vive más de unos minutos, probablemente cron no sea la herramienta.

Casos donde cron es la respuesta correcta:

• Publicación programada de contenido: postear a redes sociales a hora fija, enviar newsletters, publicar artículos.
• Backups: exportar base de datos a las 3am, subir a S3, limpiar backups viejos.
• Limpieza de archivos temporales: borrar sessions expiradas, archivos de caché, logs viejos.
• Reportes periódicos: generar un PDF con métricas del día y mandarlo por email.
• Sincronización de datos: traer datos de una API externa cada hora y guardarlos en tu base de datos.

En todos estos casos, la tarea es atómica: no depende de lo que pasó en la ejecución anterior (o si depende, lee el estado de la base de datos al arrancar). No necesita supervisión continua. Si falla una vez, el mundo no se termina. Sobre eso hablamos en herramientas de automatización de despliegues.

Cuándo elegir systemd daemon

Usá systemd cuando tu proceso de Node.js tiene que estar siempre activo o cuando necesita reaccionar a cosas en tiempo real.

Un archivo .service básico para Node.js se ve así:

[Unit]
Description=Mi API Node.js
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/miapp
ExecStart=/usr/bin/node /var/www/miapp/server.js
Restart=on-failure
RestartSec=5
EnvironmentFile=/var/www/miapp/.env

[Install]
WantedBy=multi-user.target

Con systemctl enable mi-api lo registrás para que arranque con el sistema. Con systemctl start mi-api lo levantás. Con journalctl -u mi-api -f ves los logs en tiempo real. Eso es todo lo que necesitás para tener un daemon supervisado en producción (sin instalar nada extra).

Los casos donde systemd gana por paliza: APIs REST, servidores WebSocket, procesadores de colas de mensajes como Bull o BullMQ, sistemas de monitoreo que mantienen estado en memoria, cualquier aplicación que tiene que responder a requests.

Alternativas: PM2, Supervisor y otras herramientas

PM2 merece párrafo aparte porque en el ecosistema Node.js es la herramienta de gestión de procesos más usada. Más contexto en asistentes IA para desarrollo en Node.js.

PM2

PM2 opera a nivel de aplicación, no de sistema operativo. La ventaja es que viene con cosas muy útiles para Node.js: modo cluster (múltiples procesos aprovechando todos los cores), monitoreo en tiempo real con pm2 monit, métricas de memoria y CPU, y una interfaz para ver todo el estado de tus apps de un vistazo.

La contra: es una capa de abstracción encima del sistema, con su propio daemon (pm2 corre como proceso), sus propios logs, su propia configuración. Funciona muy bien para equipos que no quieren tocar systemd y prefieren manejar todo con herramientas de Node.js. PM2 también incluye un módulo de tareas programadas que puede reemplazar cron en algunos casos, aunque es menos flexible que crontab.

node-cron (paquete npm)

Si ya tenés una app Node.js corriendo como daemon (con PM2 o systemd) y querés agregar tareas programadas dentro del mismo proceso, el paquete node-cron te permite definir schedules con sintaxis cron directamente en tu código JavaScript. La ventaja es que corre en el mismo proceso que tu app y puede acceder a todas las funciones y el estado en memoria. La contra: si el proceso se cae, las tareas programadas también se caen.

systemd timers

Según crongen.com en su análisis de 2026, systemd también tiene su propio sistema de timers que puede reemplazar cron completamente. La ventaja sobre crontab clásico: mejor integración con journald, posibilidad de definir intervalos relativos (“15 minutos después del arranque”), y gestión unificada con el resto de los servicios. La contra: la configuración es más verbose (necesitás dos archivos: un .timer y un .service). Para la mayoría de los casos, crontab es suficiente y más directo.

Errores comunes al gestionar procesos Node.js

Error 1: Usar cron para un proceso que necesita estado. El síntoma es un script que al arrancar tiene que leer un archivo o base de datos para saber qué hizo la última vez. Cada vez que esto pasa, hay fricción innecesaria y posibilidad de inconsistencias. Si el proceso necesita recordar cosas entre ejecuciones, o bien usá un daemon o bien diseñá el estado de forma que sea completamente stateless (y que la base de datos sea la fuente de verdad).

Error 2: Ejecutar Node.js en producción sin ningún mecanismo de supervisión. node server.js & en background sin systemd ni PM2. El proceso se cae por una excepción no manejada, nadie se entera hasta que un usuario reporta que la API no responde. Con systemd o PM2, el proceso se reinicia automáticamente y tenés logs de qué pasó.

Error 3: No manejar la superposición de ejecuciones en cron. Si un script tarda más de su intervalo de ejecución, cron va a lanzar una segunda instancia mientras la primera todavía está corriendo. Para tareas que escriben en base de datos o archivos, esto puede causar condiciones de carrera. La solución: usar flock para evitar ejecuciones simultáneas, o diseñar los scripts para que sean idempotentes.

Error 4: Poner credenciales directamente en el crontab. Cualquiera con acceso al servidor puede leer el crontab. Las credenciales y tokens de API tienen que ir en un archivo .env con permisos 600, que el script carga al arrancar. En mejores asistentes de código del 2026 profundizamos sobre esto.

Preguntas Frecuentes

¿Cuándo usar cron para Node.js y cuándo systemd?

Usá cron cuando el script arranca, ejecuta una tarea puntual y termina: backups, publicaciones programadas, sincronización de datos. Usá systemd cuando el proceso tiene que estar siempre activo: APIs, servidores, sistemas de monitoreo o cualquier cosa que procese requests o eventos de forma continua.

¿Qué diferencia hay entre cron y un systemd timer?

Cron es el planificador clásico de Unix: simple, una línea por tarea, ampliamente compatible. Los systemd timers ofrecen mejor integración con journald, intervalos relativos al arranque del sistema y gestión unificada con el resto de los servicios. Para la mayoría de los casos, crontab es suficiente. Los systemd timers tienen sentido si ya gestionás todo con systemd y querés centralizar.

¿Es mejor PM2, cron o systemd para ejecutar Node.js en producción?

Depende del caso. Para apps Node.js que tienen que estar siempre activas, PM2 y systemd son las opciones principales. PM2 ofrece clustering y métricas propias del ecosistema Node.js; systemd es más liviano y está integrado en el sistema operativo sin dependencias extra. Cron no reemplaza a ninguno de los dos para procesos persistentes: es para tareas programadas puntuales.

¿Cómo configurar un daemon systemd para Node.js en producción?

Creás un archivo en /etc/systemd/system/tu-app.service con la sección [Unit] (descripción y dependencias), [Service] (comando de arranque, usuario, directorio, archivo de entorno, política de reinicio) y [Install] (WantedBy=multi-user.target). Después ejecutás systemctl daemon-reload, systemctl enable tu-app y systemctl start tu-app. Los logs los consultás con journalctl -u tu-app.

¿Puedo usar cron y systemd daemon al mismo tiempo en el mismo servidor?

Sí, y es lo más común. Podés tener un daemon systemd para tu API Node.js y al mismo tiempo cron para las tareas programadas: backups, envío de emails, sincronización de datos. No se excluyen. El criterio de elección es el tipo de proceso, no el servidor.

Conclusión

La gestión de procesos Node.js en Linux tiene una respuesta clara una vez que describís bien el problema. Cron para tareas atómicas que se ejecutan en momentos específicos: simple, sin overhead, lleva décadas funcionando. systemd para procesos que tienen que vivir de forma continua: supervisión automática, logging integrado, reinicio ante fallos, todo sin instalar nada extra.

PM2 sigue siendo válido si preferís manejar todo desde el ecosistema Node.js, especialmente cuando necesitás clustering y métricas detalladas sin configurar systemd a mano.

Lo que el análisis de dev.to deja claro es que en el mismo servidor podés necesitar las dos cosas: un daemon systemd para el procesador de cola de trabajos que corre de forma continua, y cron para el script que publica contenido a las 9am. No hay contradicción. Y si montás todo esto en un servidor, un VPS con buena configuración base en donweb.com te ahorra trabajo desde el principio.

Fuentes

• dev.to – Cron vs systemd daemon: which one for Node.js? (mayo 2026)
• crongen.com – Cron vs systemd timers 2026
• crongen.com – Node.js cron jobs: system vs node-cron
• Medium – Using systemd as a better cron
• luisllamas.es – Qué es y cómo usar PM2