Tiempo y automatización en la web: cron jobs, colas y eventos programados (implementación en WordPress)

El tiempo es infraestructura. Si tus tareas programadas fallan, llegan tarde o se solapan, tu web pierde fiabilidad: emails que no salen, caches que no se purgan, backups que nunca se ejecutan. Esta guía te ayuda a pensar el tiempo como un sistema: cron del servidor, WP-Cron, colas, workers, fiabilidad y observabilidad. Cerramos con una bajada práctica a WordPress.

El tiempo en producción es un sistema: programación, ejecución, confirmación y observación.

1) Por qué el tiempo importa en la web moderna

El “tiempo” no es sólo cuándo se publica un post. En producción, es orquestación: limpiar cachés por la noche, generar feeds cada hora, ejecutar backups, enviar newsletters, reintentar pagos, expirar sesiones, rotar logs. Sin un sistema de automatización sólido, la web se llena de tareas manuales, errores fantasma y sorpresas.

Además, la escala modifica el problema: pasar de 100 a 100.000 usuarios multiplica colas, latencias y picos. Lo que funcionaba con un cron sencillo puede romperse cuando hay múltiples servidores, CDN, microservicios o picos nocturnos. Por eso, la conversación no es “¿cron o WP-Cron?”, sino qué calendario de tareas necesita tu arquitectura.

2) Modelos de ejecución: cron, eventos, colas y planificadores

Existen varios enfoques. Entenderlos te permite combinarlos con criterio:

• Cron del sistema: tareas en horarios fijos (minuto/hora/día…). Fiable, independiente del tráfico web.
• Eventos internos (p. ej., WP-Cron): tareas que se programan dentro de la aplicación y se disparan cuando se recibe tráfico.
• Colas de trabajos (jobs/queues): cada evento se encola y workers las consumen. Escalan bien con volumen; control fino de reintentos.
• Planificadores externos: servicios o herramientas que programan y orquestan flujos (Airflow, Temporal, etc.). Útiles en pipelines complejos.

No hay un “mejor” universal. Hay contextos: una web de marca con tráfico moderado puede vivir con cron + WP-Cron. Un e-commerce con picos y procesos intensivos agradecerá colas y workers dedicados.

3) Cron del sistema (cronie / systemd timers): el viejo fiable

Cron existe desde los albores de Unix. Es simple y resistente: ejecuta comandos a horas fijas. Dos sabores comunes hoy:

• cronie (crontab clásico): se edita con crontab -e.
• systemd timers: reemplazo moderno con unidades .service y .timer, logs integrados (journalctl) y más control.

3.1 Formato crontab

# m h dom mon dow  command
0 2 * * * /usr/local/bin/backup.sh
*/15 * * * * /usr/bin/php /var/www/html/artisan schedule:run

Ventajas: precisión, independencia del tráfico, logs fáciles. Contras: si tu app está en múltiples hosts, deberás decidir dónde corre (evitar ejecuciones duplicadas) y añadir bloqueos (lockfiles, flock) o un “leader” que coordine.

3.2 systemd timers (recomendado en distros modernas)

# /etc/systemd/system/myjob.service
[Unit]
Description=Mi tarea nocturna

[Service]
Type=oneshot
ExecStart=/usr/bin/php /var/www/html/scripts/limpiar.php

# /etc/systemd/system/myjob.timer
[Unit]
Description=Programador de mi tarea nocturna

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Con Persistent=true, systemd ejecuta la tarea si se perdió una ventana (servidor apagado) al volver a arrancar. Documentación: systemd.timer.

4) WP-Cron: disparo por tráfico y consideraciones reales

WordPress incorpora WP-Cron, un sistema que simula cron y dispara tareas programadas cuando alguien visita la web. Ventajas:

• No requiere acceso al servidor.
• Fácil de usar desde plugins y temas.

Contras:

• Dependiente del tráfico: si nadie entra, las tareas no corren a la hora prevista.
• En picos, puede solapar ejecuciones si no están bien bloqueadas.
• Algunas tareas (backups, importaciones pesadas) no son ideales para ejecutarse en el ciclo de una petición web.

Para sitios serios suele recomendarse desactivar el disparo automático y invocar WP-Cron desde cron del sistema. Documentación oficial: WP-Cron y funciones wp_schedule_event().

5) Colas y workers: cuando el “cuándo” depende del “cuánto”

Las colas de trabajos separan el acto de programar del acto de ejecutar. En lugar de hacerlo todo “a la hora en punto”, encolas trabajos y uno o varios workers los consumen a su ritmo. Beneficios:

• Resiliencia con reintentos y backoff.
• Escalado horizontal: más workers en picos.
• Aislamiento de tareas pesadas fuera del ciclo de petición.

Ejemplos típicos: Redis Queue (RQ), RabbitMQ, SQS, Sidekiq, Celery. Documentación de referencia: Colas en Redis, RabbitMQ Tutorials, Celery.

Para WordPress, hay plugins y librerías que integran colas basadas en la base de datos o Redis. El patrón mental sigue siendo válido: encolado, worker, reintentos, DLQ (cola de muertos) y observabilidad.

6) Diseño fiable: idempotencia, reintentos, backoff y bloqueo

Que una tarea “funcione” no basta. Debe resistir fallos: caídas de red, duplicados, tiempos límite. Principios clave:

• Idempotencia: ejecutar dos veces no debe romper nada ni duplicar efectos. Si tu tarea envía emails, guarda un job_id y marca como enviado; si vuelve a correr, detecta que ya está hecho.
• Reintentos con backoff exponencial: ante error transitorio, reintenta en 1s, 2s, 4s, 8s… con tope. Evita tormentas de reintentos simultáneos (thundering herd).
• Bloqueos (locks): para impedir solapes. Usa flock, mutex en Redis o tablas de control. Un lock siempre debe tener caducidad para evitar deadlocks.
• Tiempo máximo (timeout): si una tarea tarda demasiado, cancelarla es mejor que dejarla colgada.
• Compensación: si una mitad del proceso salió bien y la otra falló, define pasos para deshacer (cancelaciones, reembolsos, limpiar estados intermedios).

En colas maduras, todo esto viene “de serie”. En cron simple, tendrás que implementarlo tú (scripts con locks, retries y alerts).

7) Zonas horarias, UTC y horario de verano (Europe/Madrid)

El tiempo tiene trampas: zonas horarias, cambios de horario de verano (DST) y servidores en UTC. Buenas prácticas:

• UTC en servidor: programa y guarda timestamps en UTC. Convierte a la zona del usuario en la interfaz.
• Europe/Madrid alterna CET (UTC+1) y CEST (UTC+2). Durante el cambio, los minutos “se repiten” o “desaparecen”. Usa planificadores que entiendan OnCalendar con TZ o expresa cron en UTC.
• No confíes en “siempre a las 02:00 locales” para tareas críticas en días de cambio. Prefiere UTC o añade lógica para el día especial.

Para systemd timers puedes especificar zona horaria a nivel de servicio o ejecutar siempre en UTC y convertir en aplicación.

8) Observabilidad: logs, métricas y alertas para tareas programadas

Automatizar sin observar es misión a ciegas. Necesitas:

• Logs estructurados con job_id, inicio, fin, estado, duración, reintentos.
• Métricas: tareas por minuto, errores, tiempo medio, tareas en cola.
• Alertas: si una tarea crítica no corre en X minutos; si la duración se dispara; si la cola supera un umbral.
• Tablero (dashboard): visibilidad simple para negocio (¿salió la newsletter?) y técnica (¿fallaron 3 jobs?).

En systemd, usa journalctl -u myjob.service. En colas, revisa métricas del broker (Redis, RabbitMQ) o integra Prometheus/Grafana.

9) Casos prácticos de automatización en sitios web

• Backups nocturnos: cron a las 02:00 UTC, lock para evitar solape, subida a almacenamiento externo, verificación de integridad, alerta en fallo.
• Purga de cachés: cada hora, y también bajo demanda tras despliegue.
• Generación de sitemaps: según cambios; cola para regenerar sin bloquear la petición.
• Emails transaccionales: encolados con reintentos; evitar enviarlos desde el request web.
• Importaciones: partir en lotes; worker consume; resumen al final con métricas.
• Reglas de negocio: expirar ofertas a medianoche UTC; actualizar stocks; recalcular puntuaciones.

10) WordPress: cómo elegir y montar tu estrategia

En WordPress tienes tres escenarios típicos:

1. Solo WP-Cron: válido para sitios pequeños/medianos sin tareas críticas de horario exacto.
2. WP-Cron invocado por cron del sistema: equilibrio excelente; precisión razonable y control centralizado.
3. Colas reales para tareas pesadas (emails masivos, importaciones, generación de PDFs) + cron para disparos y mantenimiento.

10.1 Programar eventos en WordPress

WP ofrece wp_schedule_event() y ganchos. Referencia: wp_schedule_event(), Guía WP-Cron.

10.2 Desactivar el disparo automático de WP-Cron

// wp-config.php
define('DISABLE_WP_CRON', true);

Así evitas que cada visita intente disparar cron. Luego, invócalo desde el sistema:

10.3 Cron del sistema invocando WP-Cron

# Cada 5 minutos
*/5 * * * * /usr/bin/curl -s https://tusitio.com/wp-cron.php?doing_wp_cron=1 > /dev/null 2>&1

O con WP-CLI (preferible si lo tienes):

*/5 * * * * /usr/bin/wp cron event run --due-now --path=/var/www/html > /var/log/wp-cron.log 2>&1

Documentación WP-CLI cron: wp cli cron.

10.4 Bloqueo para evitar solapes

Usa un lockfile simple en el sistema cuando invoques procesos más pesados:

*/5 * * * * /usr/bin/flock -n /tmp/wp-cron.lock /usr/bin/wp cron event run --due-now --path=/var/www/html

10.5 Qué tareas pasar a colas

• Emails masivos (newsletters, campañas).
• Procesamiento de imágenes (thumbnails en lote).
• Importaciones/exports grandes.
• Sincronizaciones con terceros (APIs) para evitar timeouts del request.

10.6 Señales de que WP-Cron “no llega”

• Eventos que se acumulan (muchos “overdue”).
• Tareas que sólo corren cuando tú abres el admin.
• Horas inexactas o grandes retrasos.

Solución: invocar desde cron real y revisar métricas.

11) Migrar de WP-Cron al cron del sistema (paso a paso)

1. Audita eventos programados: qué, cada cuánto, duración, criticidad.
2. Desactiva disparo automático con DISABLE_WP_CRON.
3. Crea cron del sistema cada 5 minutos que invoque WP-CLI.
4. Bloquea con flock para evitar solapes.
5. Registra logs y métricas (tiempo, errores, jobs ejecutados).
6. Prueba en staging un ciclo completo de 24–48 h y revisa.
7. Produce y deja alertas: si no corre en 10 min, avisa.

12) FAQ

¿Cada cuánto debo invocar WP-Cron desde el sistema?

5 minutos es una frecuencia razonable para la mayoría de sitios. Si tienes eventos a minuto fijo o colas grandes, baja a 1–2 minutos. Mide antes de decidir.

¿Puedo usar sólo colas y olvidarme de cron?

Las colas resuelven volumen, no calendario. Aun así necesitas disparar tareas (cron o planificador) para checks periódicos, limpieza, etc.

¿Qué hago si una tarea tarda más que el intervalo programado?

Aplica locks para no solapar, y considera partir la tarea en sub-tareas encoladas. Aumenta el intervalo o dedica más workers.

¿Cómo evito duplicados al reintentar?

Idempotencia: guarda marcadores (por ejemplo, “pedido #123 ya procesado”). Si vuelves a correr, detecta el estado y sal con éxito sin repetir efectos.

¿El horario de verano me puede romper tareas?

Sí, si programas en hora local. Usa UTC en servidor y convierte sólo en interfaz; para tareas críticas en días de cambio, trata el día como especial.

13) Checklist de producción

1. Define qué corre, cuándo corre y dónde corre (host líder, locks).
2. Elige modelo: WP-Cron solo / WP-Cron invocado por cron / colas + cron.
3. Establece idempotencia y reintentos con backoff.
4. Implementa locks (flock/Redis) y timeout por tarea.
5. Logs con job_id, duración y estado; métricas y alertas (si no corre en X minutos, avisa).