Una empresa de comercio electrónico descubre un lunes que no se han exportado pedidos al ERP durante doce días. El script cron se está ejecutando: entrada crontab correcta, archivo de registro con fecha de esta mañana. En realidad, el trabajo falla en la conexión SFTP desde un cambio de clave, pero el desarrollador no redirigió stderr, nadie monitorea el código de salida y el compartido no notifica.
Los trabajos cron son invisibles por diseño. Funcionan de noche, sin un usuario delante de la pantalla. Precisamente por eso requieren más observabilidad que una página web, no menos.
Anatomía de un cron de producción
| Elemento | Mala práctica | Buenas prácticas |
|---|---|---|
| Salir | /dev/nulo | Registro estructurado + rotación |
| Fracaso | Ignorado | Alerta si sale ≠ 0 |
| Duración | No medido | Tiempo de espera + alerta de desbordamiento |
| Competencia | Doble ejecución | Bloqueo de bandada / Redis |
| Idempotencia | No | Rejugable sin doble efecto |
Un cron que “se ejecuta” sin pruebas de éxito empresarial no se ha ejecutado: solo ha consumido CPU.
Compartido vs VPS: ¿hacia dónde gira tu noche?
Compartido:
- Baja precisión del tiempo; se superponen con trabajos vecinos.
- cron
mail()a menudo deshabilitado o filtrado como spam. - Sin temporizador systemd avanzado.
VPS/nube:
- Temporizadores systemd con
Persistent=true(puesta al día perdida). - Registros de diario centralizados.
- Trabajadores dedicados para trabajos pesados.
Para sincronización de facturación o acciones, compartir es una apuesta. Para la purga de caché semanal, aceptable.
Patrón de observabilidad mínimo
- Cáscara envolvente:
#!/bin/bash
conjunto -euo pipefail
LOG=/var/log/jobs/export-erp.log
{
echo "=== $(fecha -Es) inicio ==="
/usr/bin/php /app/bin/export-erp.php
echo "=== $(fecha -Está) bien ==="
} >> "$LOG" 2>&1 || curl -fsS -m 10 --reintentar 3 https://hc.example/ping/xxx-fail
- Healthchecks.io / Cronitor — ping a INICIO y ÉXITO; alerta si está ausente.
- Métrica de duración: Grafana o registro analizado simple; alerta si > 2× mediana.
- Runbook: enlace en alerta al procedimiento manual.
Consulte Crontab y bloqueo y Apio: evitar que una cola de tareas se convierta en una caja negra.
Idempotencia y cerraduras
Escenario clásico: la importación de productos dura 25 minutos, cron cada 15 minutos → dos importaciones corrompen la base de datos.
Soluciones:
- flock -n al inicio del script; sáltelo si ya está en progreso.
- Redis SET NX con TTL > duración máxima del trabajo.
- Bloqueo de asesoramiento de PostgreSQL para trabajos centrados en bases de datos.
Cada trabajo crítico debe ser reproducible: reiniciar sin duplicar las escrituras (UPSERT, marcador de id_batch).
Migración cron → cola
| Señal | Acción |
|---|---|
| Trabajo > 5 minutos | Trabajador + cola |
| Reintentar con retroceso | Apio / Mensajero |
| Dependencias entre trabajos | Orquestador (temporal, luz de flujo de aire) |
| Visibilidad del equipo | Tablero Flor / Horizonte |
El cron sigue siendo útil para activar (0 2 * php bin/console messenger:consume), no para ejecutar todo en línea.
La cumbre: el fallo de cron siempre lo descubre la profesión, nunca la tecnología
El anfitrión vende “cron incluido”. Su responsabilidad: demostrar el éxito o el fracaso independientemente del anfitrión del panel.
Decide y avanza sin puntos ciegos
- Inventario de todos los crons (crontab + panel + CI).
- Clasifique la criticidad y agregue controles de salud externos a las revisiones.
- Bloquear trabajos > 1 min o intervalo corto.
- Fallo de la prueba voluntario: ¿la alerta llega en < 5 minutos?
- Propietario del documento y runbook por trabajo.
Compare PaaS con cron observable (Alwaysdata) a través de nuestro directorio.
Preguntas frecuentes
¿Por qué los crons compartidos no son confiables?
Ventanas inexactas, carga compartida, sin notificación de fallas: riesgosos para la sincronización crítica.
¿Cómo sé si un cron ha fallado?
Código de salida registrado + ping externo o alerta; El silencio no es el éxito.
¿Se necesita un candado para evitar duplicados?
Sí, si la duración del trabajo es ≥ intervalo: rebaño, Redis o bloqueo de aviso.
¿Cron del sistema o cola?
Cron para abreviar y raro; cola + trabajadores durante mucho tiempo, reintento y visibilidad.
Un cron confiable no se ve por la noche: se prueba por la mañana o alerta antes de que la empresa lo note.