Contenedores
Una alternativa al cron de Docker que también monitoriza CronJobs de Kubernetes
Deja de ejecutar daemons cron dentro de contenedores. Haz que SteadyCron dispare tus jobs desde fuera, o mantén tu cron de Docker/K8s actual y simplemente monitorízalo con un heartbeat.
El problema
El cron dentro de un contenedor es una fuente recurrente de problemas: el daemon necesita su propia supervisión de proceso en una imagen que de otro modo sería de un solo proceso, los logs quedan atrapados en el stdout del contenedor en lugar de tu agregador, y la zona horaria del contenedor se desincroniza silenciosamente de lo que esperas. Los CronJobs de Kubernetes resuelven el problema del daemon pero no el de visibilidad — un CronJob que deja de crear Pods silenciosamente (un horario en pausa, una imagen defectuosa, un backoffLimit agotado) falla de forma completamente silenciosa. Nada en kubectl te dice que un job debería haberse ejecutado hace una hora.
Cómo lo resuelve SteadyCron
- 1 Opción A — sacar el disparador del contenedor por completo: expón un endpoint HTTP sencillo en tu app y deja que SteadyCron lo llame según el horario, con sus propios retries y timeout. Sin daemon cron, sin proceso adicional, sin sorpresas de zona horaria dentro de la imagen.
- 2 Opción B — mantén tu cron de Docker o CronJob de Kubernetes actual, y añade un heartbeat: el job hace ping a la ping URL de SteadyCron al tener éxito (o /fail en caso de error) como último paso.
- 3 En ambos casos, SteadyCron rastrea lo esperado frente a lo real: si el ping (o la llamada HTTP) no llega dentro del periodo de gracia que configures, el check pasa de a tiempo a perdido.
- 4 Recibes una alerta en el momento en que un CronJob deja de dispararse — no cuando alguien nota que el informe nocturno nunca llegó.
# Añadir a un CronJob de Kubernetes existente: ping en éxito, alerta si perdido/fallido
command: ["/bin/sh", "-c"]
args:
- >
./run-job.sh &&
curl -fsS https://ping.steadycron.com/$PING_TOKEN ||
curl -fsS https://ping.steadycron.com/$PING_TOKEN/fail
Jobs
| weekly-digest-email | HTTP | 0 9 * * 1 | in 2 days | 3 days ago | ||
| nightly-db-backup | Heartbeat | 0 2 * * * | in 19 h | 5 h ago | ||
| stripe-reconciliation | HTTP | 0 */4 * * * | in 38 min | 3 h ago | ||
| cache-warmup | HTTP | */15 * * * * | in 11 min | now | ||
| search-index-sync | Heartbeat | */30 * * * * | in 6 min | 24 min ago |
| seed-test-data | HTTP | 0 4 * * * | in 14 h | 10 h ago | ||
| preview-env-cleanup | Heartbeat | 0 */6 * * * | in 2 h | 4 h ago | ||
| trial-expiry-sweep | HTTP | 0 6 * * * | — | yesterday |
Estado, horario y última ejecución de cada job — de un vistazo.
Dos formas de arreglar el cron en contenedores, según lo que controles
Si eres dueño del código de la app: elimina el cron dentro del contenedor por completo. Añade un endpoint HTTP que ejecute la lógica del job, y deja que SteadyCron lo llame desde fuera según el horario — con su propio retry/backoff y un registro completo de peticiones. El contenedor vuelve a ejecutar un solo proceso, como debería, y el horario vive en SteadyCron en lugar de en un archivo crontab que tiene que sobrevivir a cada reconstrucción de imagen.
Si no quieres tocar el disparador (un CronJob de Kubernetes que posee
otra persona, un entrypoint de Docker que prefieres no refactorizar ahora
mismo): déjalo corriendo y añade un heartbeat
check. Un curl al final del script, y
SteadyCron sabe si el job se ejecutó — y te alerta en el momento en que no lo
hace, en lugar de que te enteres por un síntoma downstream.
Por qué el cron en contenedores falla específicamente de esta forma
- Docker: un daemon cron dentro de un contenedor es un segundo proceso de
larga duración que compite con el
PID 1que tu orquestador realmente supervisa. Si el daemon muere, el contenedor sigue pareciendo sano —docker psmuestra “running” — mientras nada dentro de él se está disparando. - CronJobs de Kubernetes: el horario en sí es fiable (el controlador es
parte del control plane), pero el fallo es invisible por diseño. Un
CronJob que alcanza su
backoffLimit, unstartingDeadlineSecondsdemasiado ajustado en un clúster ocupado, o una etiqueta de imagen incorrecta fallan todos de la misma forma: sin Pod, sin error en tus dashboards, solo un job que silenciosamente dejó de ocurrir.
Si estás depurando esto en vivo, consulta los desgloses específicos de la plataforma: cron de Docker no se ejecuta · CronJob de Kubernetes no se ejecuta.
Encaja bien para
- Jobs batch nocturnos, backups y generación de informes actualmente disparados por un daemon cron integrado en una imagen Docker.
- CronJobs de Kubernetes para limpieza, sincronización o tareas de mantenimiento donde una ejecución perdida es fácil de pasar por alto hasta que se acumula.
- Equipos que avanzan hacia un modelo donde el horario vive fuera del contenedor, para que escalar, redeployar o migrar de clúster no arriesgue perder el horario junto con el Pod.
Documentación relacionada
Deja de enterarte a las malas
Empieza en el plan gratuito — sin tarjeta de crédito.
Empezar gratis