El backup que se detuvo en silencio
Un cron de pg_dump termina con código 1 desde el día 4. Nadie lo notó, porque un job que falla no escribe nada en un panel ni envía ningún email. Te enteras durante una restauración, el momento más caro posible.
Cronitorex vigila tus cron jobs, scripts de deploy, endpoints HTTP y certificados SSL. Envía un ping desde cualquier script y recibe una alerta en 60 segundos. No hace falta construir tu propia infraestructura de monitoreo desde cero.
# Cron, deploy, ETL, backup, worker: envuelve lo que sea en 3 líneas curl -sf https://api.cronitorex.com/ping \ -H "Authorization: Bearer $CRONITOREX_API_KEY" \ -d '{"event_type":"ping","monitor":"db-backup","status":"run"}' /usr/local/bin/backup.sh # tu script, lo que sea que ejecutes curl -sf https://api.cronitorex.com/ping \ -H "Authorization: Bearer $CRONITOREX_API_KEY" \ -d '{"event_type":"ping","monitor":"db-backup","status":"complete","duration":47.3}'
Funciona con cualquier script ejecutado desde shell: bash, Python, GitHub Actions, CronJob de k8s, tarea de Airflow, hook de deploy.
La mayoría de las caídas no se anuncian. Se ven así:
Un cron de pg_dump termina con código 1 desde el día 4. Nadie lo notó, porque un job que falla no escribe nada en un panel ni envía ningún email. Te enteras durante una restauración, el momento más caro posible.
La renovación estaba automatizada, hasta que alguien movió el registro DNS. El certificado expiró a las 2:13 AM y el checkout mostró una advertencia de seguridad hasta el lunes. Nada en el stack consideró esto un error.
El servidor dice que el proceso está activo. Los usuarios igual reciben un 502 del load balancer. Desde adentro todo se ve saludable, precisamente por eso la solicitud tiene que venir de afuera.
Cronitorex fue creado para estos tres momentos.
Diseñado para desarrolladores que quieren control total sobre su stack de monitoreo.
Tres pings. Visibilidad completa.
Una solicitud HTTP por ping. Cronitorex las correlaciona en una línea de tiempo, detecta ejecuciones perdidas y envía alertas en cuestión de segundos. Sin agentes. Sin daemons. Solo tres pings.
Envía un ping run al comienzo de tu job.
{"status": "run"}Tu tarea real se ejecuta. Cronitorex espera.
/usr/bin/backup.shEnvía complete o fail. El panel se actualiza al instante.
{"status": "complete"}Un vistazo rápido a lo que Cronitorex te muestra todos los días. Haz clic en las pestañas.
La ejecución terminó con exit 1. Alerta enviada a Telegram y por email.
La API upstream devolvió 401 después de una rotación de clave. Solución en curso.
El chequeo HTTP falló 3 veces seguidas con un 503.
Incidente del proveedor cerrado. Los chequeos vuelven a estar en verde.
Email, webhook, Telegram y Discord en todos los planes. Slack desde Pro. PagerDuty en Business.
El polling externo y el scraping de logs se pierden cada uno una categoría completa de fallos. Los pings cierran esa brecha.
Un chequeo te dice que el servidor respondió. No puede decirte que el backup de las 2 AM nunca arrancó, porque no hay una URL que consultar sobre un job que no corrió.
Los logs registran todo y no alertan sobre nada. Buscar con grep el stack trace de ayer es arqueología; para cuando alguien lo lee, el daño ya está hecho.
Un job que reportó run y nunca reportó complete está colgado. Un job que no reportó nada está muerto. Ambos disparan una alerta en menos de un minuto, con el código de salida y el stderr adjuntos.
Cronitorex hace las dos cosas: pings desde adentro, chequeos desde afuera. Ver cómo funciona →
Elige los monitores que quieres mostrar y Cronitorex publica una página de estado con estado en vivo, porcentajes de uptime e historial de incidentes. Escribes actualizaciones mientras investigas, así el soporte deja de responder el mismo email una y otra vez. Disponible en todos los planes, con su propia dirección.
Seis escenarios típicos donde Cronitorex demuestra su valor.
Si puede enviar una solicitud HTTP, se puede monitorear. Sin agentes, sin SDK, sin reglas de firewall: los pings salen desde tu lado.
Una línea con curl es suficiente. La documentación tiene snippets listos para cada entorno. Explorar la documentación →
Sí. Cronitorex monitorea cron jobs de producción, endpoints HTTP y certificados SSL todos los días. El tráfico de producción es bienvenido en todos los planes, incluido el plan Free.
Cronitorex expone una API HTTP estándar con el patrón run/complete/fail. Si tu herramienta actual usa un modelo de ping similar, la migración se reduce a cambiar la URL y la API key en los scripts que ya tienes. La referencia completa de la API está en docs.cronitorex.com, y una guía de migración paso a paso cubre el cambio desde Cronitor, PostPing y otras herramientas.
Las notificaciones por email, Telegram, Discord y webhook están disponibles en todos los planes. Slack se incluye desde el plan Pro. Los webhooks te permiten conectar cualquier endpoint HTTP, lo que habilita integrar tú mismo cualquier servicio externo.
Sí. Elige qué monitores publicar y Cronitorex genera una página de estado pública con estado en vivo, porcentajes de uptime e historial de incidentes, disponible en todos los planes, incluido el plan Free.
Alojados en nuestra propia infraestructura en la UE, conforme al RGPD. Todo el tráfico pasa por HTTPS (TLS 1.3), ningún ping viaja jamás en texto plano. La base de datos está en una red privada, accesible solo desde nuestros servicios de aplicación. Las contraseñas de los usuarios se guardan como hashes criptográficos. Puedes rotar tu API key en cualquier momento desde la página de perfil: la anterior deja de funcionar de inmediato. Backups diarios de la base de datos, cifrados, con retención de 30 días. Exportación completa de datos y eliminación de cuenta desde el panel. No vendemos ni compartimos datos con terceros. ¿Necesitas un informe de auditoría o un despliegue on-premise? Escribe a hello@cronitorex.com.
Regístrate, consigue una API key, pega el curl en tu cron. Eso es todo.