En entornos con tráfico variable, WP‑Cron tiende a saltarse tareas programadas y a disparar ejecuciones concurrentes que provocan picos de CPU o pérdida de correos, backups y procesos críticos. Empresas y equipos TI que requieren fiabilidad detectan retrasos, duplicados o fallos silenciosos cuando la programación depende del tráfico web.
Alternativas a WP‑Cron: sustituirlo por un cron real u opciones como systemd timers, servicios externos (Healthchecks.io), colas (Redis/RabbitMQ) o ejecutar tareas con WP‑CLI. Cada opción aporta mayor fiabilidad y control; la elección depende del acceso al servidor, el volumen de tareas y el coste. Añadir monitorización y locking evita ejecuciones solapadas y pérdida de tareas.
Comparativa rápida
La tabla resume precisión, coste, facilidad y limitaciones para elegir con rapidez según el perfil del proyecto.
| Opción |
Precisión |
Duración soportada |
Coste medio (ES) |
Facilidad (1‑5) |
Locking automático |
| Cron sistema (crontab) |
1–5 min |
Corta a media (seg‑minutos) |
0€–hosting |
3 |
No (usar flock) |
| systemd timers |
1–1 min (estable) |
Corta a media |
0€–infra |
3 |
No (requiere usar flock u otro mecanismo de locking; el locking no es automático en systemd ni en crontab, debe implementarse explícitamente) |
| Servicios externos (Cronitor, Healthchecks) |
1 min |
Webhook corto |
0–30 €/mes |
5 |
No |
| Colas (Redis / RabbitMQ) |
Por diseño (consistente) |
Larga (minutos‑horas) |
10–200+ €/mes |
2–3 |
Sí |
| Kubernetes CronJobs |
1 min |
Media a larga |
Segmento infra |
2 |
Sí (concurrencyPolicy) |
La elección depende de tres criterios medibles: acceso al servidor, volumen de tareas concurrentes y coste mensual. Para la mayoría de comercios digitales, un cron del sistema con locking reduce tareas perdidas a 0 en 72 horas si se vigila con un servicio de healthchecks.
¿Acceso SSH?
Si no, usar servicio externo o API del hosting. Si sí, valora cron del sistema o colas.
¿Tareas largas?
Si las tareas duran minutos u horas, usar colas y workers dedicados.
Cron del sistema: crontab y systemd timers
Reemplazar WP‑Cron por un cron del sistema o systemd timers elimina llamadas HTTP innecesarias y garantiza ejecución periódica, siempre que se añada locking para evitar solapamientos. Esta alternativa es la más simple y económica cuando se tiene control del servidor.
Systemd timers y flock
Usar systemd timers con flock evita que dos instancias se ejecuten a la vez. El siguiente ejemplo ejecuta WP‑CLI cada 5 minutos y respeta el locking.
Ejemplo (systemd):
[Unit]
Description=Run WP Cron via WP‑CLI
[Service]
Type=oneshot
ExecStart=/usr/bin/flock -n /var/lock/wp-cron.lock /usr/bin/wp cron event run --due-now --path=/var/www/html
[Unit]
Description=Timer for WP Cron
[Timer]
OnCalendar=*:0/5
Persistent=true
[Install]
WantedBy=timers.target
La práctica real muestra que usar flock reduce ejecuciones concurrentes y evita duplicar backups. El error más frecuente en este punto es activar DISABLE_WP_CRON sin tener el cron del sistema ya funcionando, lo que deja tareas críticas sin ejecutarse.
Crontab en hosts compartidos
Cuando no hay systemd, crontab ofrece una alternativa universal. La línea típica llama a wp-cron.php de forma segura.
Ejemplo (crontab):
*/5 * * * * /usr/bin/curl -fsS --compressed 'https://midominio.com/wp-cron.php?doing_wp_cron=1&secret=TOKEN' >/dev/null 2>&1
Nunca usar intervalos menores a 5 minutos en servidores compartidos sin hablar con el proveedor. La mayoría de guías olvidan aconsejar el token secreto y la restricción por IP; olvidarlo es una fuente común de abuso y carga HTTP.
En entornos donde no está disponible systemd —por ejemplo containers ligeros, VPS con init minimalista o ciertos hosts compartidos sin cPanel— supervisores de procesos como supervisord o runit son una alternativa práctica para mantener workers persistentes y evitar depender de WP‑Cron. Con supervisord se puede definir un programa que ejecute un worker PHP o WP‑CLI en bucle, gestionar reinicios automáticos, rotación de logs y límites de memoria, y combinarlo con flock para locking.
Un ejemplo de uso real es ejecutar un consumidor de colas Redis supervisado por supervisord que reinicie el proceso tras fallos y exporte logs a syslog para monitorización; esto facilita integrarlo con herramientas de monitorización y alertas (Prometheus/Alertmanager o Cronitor/Healthchecks.io) y reduce picos de CPU por ejecuciones concurrentes no controladas.
Colas con redis o RabbitMQ
Para trabajos largos, en masa o que requieren reintentos, las colas con Redis o RabbitMQ y workers dedicados son la alternativa más escalable frente a WP‑Cron. Estas colas gestionan orden, retries y confirmaciones.
Diseño de workers y reintentos
Diseñar la cola con reintentos limitados y backoff previene acumulación de fallos. Recomendación técnica: 3 reintentos y backoff exponencial (2^n segundos).
El siguiente esquema es práctico: job_id único, max_retries=3, backoff=2^n. Esto evita efectos duplicados cuando una tarea falla y se reintenta.
Integrarlo con action scheduler y WP‑CLI
Action Scheduler es el motor que usa WooCommerce para background jobs y funciona bien con colas externas. Ejecutar jobs mediante WP‑CLI permite trazabilidad y control.
Ejemplo de worker en PHP que consume Redis queue (resumido):
php
<?php
// worker.php (resumen)
$lock = '/var/lock/worker.lock';
if (!flock(fopen($lock, 'w'), LOCK_EX | LOCK_NB)) exit;
while ($job = pop_from_redis_queue()) {
// procesar job con idempotencia
process_job($job);
}
Un caso habitual: un comercio activó colas sin idempotencia y duplicó envíos de email tras reiniciar workers, lo que generó reclamaciones. Esto funciona bien en teoría, pero en la práctica exige pruebas de idempotencia y supervisión activa.
Servicios externos y healthchecks
Servicios como Cronitor, Healthchecks.io o EasyCron ejecutan webhooks a wp-cron.php y ofrecen monitorización y alertas con bajo coste. Son la opción más rápida cuando no hay acceso al servidor.
Llamadas seguras a wp-cron.php
Siempre proteger el endpoint que dispara wp-cron.php con un token y validarlo en WordPress antes de ejecutar cualquier tarea crítica. Ejemplo de validación mínima en functions.php:
php
add_action('init', function(){
if (isset($_GET['secret']) && $_GET['secret']==='TOKEN_SECRETO') {
// validar origen y ejecutar
}
});
No enviar datos personales en la URL. Si el webhook procesa datos personales, revisar la RGPD y firmar acuerdos con el proveedor.
Monitorización y alertas
Configurar alertas tras dos ejecuciones fallidas y enviar notificaciones a correo o PagerDuty reduce el tiempo medio de reparación. Healthchecks y Cronitor permiten definir "alert after" en minutos y escalado por niveles.
Según las políticas de proveedores, los planes básicos ofrecen checks cada 1 minuto, y las notificaciones ayudan a detectar fallos en menos de 15 minutos.
Cuando el proveedor gestionado restringe crontabs o bloquea llamadas HTTP internas, conviene usar programadores externos o funciones serverless que llamen un endpoint seguro en el WordPress (webhook autenticado) o que ejecuten comandos remotos vía SSH. Opciones concretas incluyen: configurar un CloudWatch Events → AWS Lambda (o Cloudflare Workers cron) que ejecute wp‑cli sobre una instancia accesible o que haga una llamada HTTPS firmada; usar GitHub Actions o un runner CI como scheduler para ejecutar scripts WP‑CLI mediante SSH; o programadores PaaS como Cronitor/Healthchecks.io que pingean un endpoint con token.
En todos los casos hay que proteger el endpoint (token, IP allowlist, HMAC) y monitorizar con Healthchecks.io/Cronitor para detectar missed runs y activar PagerDuty o correo ante fallos.
Jobs en contenedores: docker y kubernetes
En infra cloud‑nativa, ejecutar tareas con Docker o Kubernetes CronJobs facilita versionado y control de concurrencia. Es ideal cuando la infraestructura ya corre en contenedores.
CronJob mínimo para kubernetes
Usar concurrencyPolicy: Forbid evita solapamientos entre ejecuciones. Ejemplo compacto:
yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: wp-cron
spec:
schedule: "/5 * * * "
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
containers:
- name: wp-cli
image: myrepo/wp-cli:latest
command: ["sh","-c","/usr/bin/flock -n /var/lock/wp-cron.lock /usr/bin/wp cron event run --due-now --path=/var/www/html"]
restartPolicy: OnFailure
Configurar successfulJobsHistoryLimit y failedJobsHistoryLimit para evitar acumulación de objetos en el clúster. Además, exportar métricas a Prometheus permite vigilar latencia y fallos.
Docker compose: servicio cron
En Docker Compose, crear un servicio que ejecute WP‑CLI en bucle con sleep funciona para entornos pequeños. Asegurar volúmenes compartidos para locks.
Un error frecuente: olvidar volumen para lock, lo que provoca reinicios que lanzan jobs duplicados.
Checklist migración, scripts WP‑CLI y benchmarks
Migrar WP‑Cron requiere pasos claros, scripts robustos y métricas antes y después para validar la mejora. Seguir un checklist reduce el riesgo de pérdida de tareas.
Scripts WP‑CLI listos
Ejemplo de script shell con flock y WP‑CLI para cron o systemd:
sh
LOCK=/var/lock/wp-cron.lock
/usr/bin/flock -n "$LOCK" /usr/bin/wp cron event run --due-now --path=/var/www/html --skip-plugins --skip-themes
Comandos útiles para pruebas: wp cron event list, wp cron event run --due-now y wp action-scheduler run.
Checklist de migración
- Hacer backup completo (DB + archivos).
- Medir baseline: CPU %, TTFB (ms), tasks/hr.
- Crear entorno staging idéntico.
- Implementar locking y script en staging.
- Definir DISABLE_WP_CRON=true en staging.
- Configurar la alternativa (cron/systemd/servicio/cola).
- Hacer dry‑run 24–72 horas y comparar métricas.
- Ajustar intervalos y reintentos.
- Planificar despliegue en ventana low‑traffic.
- Monitorizar 72 horas con alertas.
- Documentar proceso y rollback.
- Entregar runbook al equipo TI.
Benchmarks y métricas a recoger
Medir CPU medio y p99, TTFB y duración media de jobs. Objetivo aceptable: reducir missed runs a 0 y no aumentar CPU p99 más del 10% respecto al baseline. Tomar estas medidas durante 72 horas para validar.
No es necesario cambiar WP‑Cron en sitios pequeños con poco tráfico o tareas no críticas donde la simplicidad prima. Tampoco aplica si el hosting gestionado garantiza ejecución fiable y monitorizada de WP‑Cron y no se dispone de control del servidor.
Para proyectos con impacto crítico, es recomendable pedir una revisión técnica especializada antes de migrar, para adaptar la solución al entorno y al cumplimiento legal.
Un script WP‑CLI para producción debe incluir logging con timestamps, códigos de salida claros, retries con backoff y rotación de logs para evitar llenar disco. Un patrón efectivo es:
- Adquirir lock con /usr/bin/flock para evitar solapamientos
- Ejecutar wp cron event run --due-now --path=/ruta --skip-plugins --skip-themes y capturar salida y código de retorno
- En caso de fallo hacer N reintentos con backoff exponencial (sleep 2^n), registrar cada intento en un fichero rotado por logrotate y devolver un código de salida distinto por tipo de error para que el supervisor o el servicio de monitorización actúe. Este enfoque con WP‑CLI y locking reduce duplicados y facilita la integración con monitorización de tareas y alertas ante picos de CPU o fallos repetidos
Preguntas frecuentes
¿Cuáles son las alternativas a cron?
Las alternativas incluyen cron del sistema (crontab/systemd), servicios externos (Cronitor, Healthchecks), colas con Redis o RabbitMQ y jobs en contenedores (Docker/Kubernetes). La elección depende de precisión (minutos), coste (0–200+ €/mes) y escala.
¿Cuál es la alternativa a cron en python?
En Python, alternativas comunes son APScheduler y Celery con Redis o RabbitMQ como broker. Celery se usa para trabajos distribuidos y largos; APScheduler sirve para tareas programadas simples.
¿Cómo puedo deshabilitar WP‑Cron?
Añadir define('DISABLE_WP_CRON', true); en wp-config.php y activar inmediatamente una alternativa (crontab/systemd/servicio externo). No dejarlo deshabilitado sin alternativa; configurar la alternativa (crontab, systemd timer, servicio externo o colas) antes de activar define('DISABLE_WP_CRON', true) para evitar pérdida de tareas críticas.
¿Cuál es otro nombre para cron?
Otro nombre habitual es "job scheduler" o "trabajo programado"; en systemd se llaman "timers" y en Kubernetes "CronJobs".
¿Qué debo monitorizar tras migrar WP‑Cron?
Monitorizar missed runs, tiempo medio de ejecución de jobs, CPU en ventanas de ejecución y alertas tras 2 runs fallidos. Enviar métricas a Cronitor o Prometheus para revisar tendencias.
¿Afecta la RGPD al uso de servicios externos?
Sí. Si las llamadas incluyen o procesan datos personales, revisar RGPD/LOPDGDD y firmar acuerdos de tratamiento con el proveedor. Evitar enviar datos personales en URLs públicas.
¿Qué herramienta usa WooCommerce para background jobs?
WooCommerce usa Action Scheduler (Automattic y Pippin Williamson) y puede ejecutarse vía WP‑CLI o con workers externos para mayor escalabilidad.
Recomendación final y siguientes pasos
Para sitios con control del servidor y tareas periódicas cortas, usar cron del sistema con flock y monitorización externa ofrece la mejor relación fiabilidad/coste. Para tareas largas o alto volumen, diseñar colas con Redis/RabbitMQ y workers supervisados es la opción más robusta.
La evidencia práctica indica que más del 43% de los sitios usan WordPress, por lo que una mala gestión de crons tiene impacto real en muchos servicios; revisar y corregir la estrategia de tareas programadas en un plazo de 72 horas es una medida razonable. Para documentar el cambio, añadir scripts WP‑CLI, políticas de reintento y un playbook de 12 pasos evita sorpresas.
W3Techs muestra el alcance de WordPress y ayuda a valorar el impacto de decisiones operativas.
Si el equipo prefiere un chequeo técnico, una auditoría de 72 horas con scripts de prueba y monitorización devuelve datos concretos para decidir la alternativa óptima.
