Migrar desde crontab

Un crontab dispara y olvida. No hay reintentos, ni timeouts, ni alertas si el script falla silenciosamente, y ningún registro de qué se ejecutó o qué devolvió. Esta guía asigna un crontab típico a un manifiesto de SteadyCron y explica qué se gana con ello.

Un crontab típico

# /etc/cron.d/myapp
MAILTO=""

# Weekly digest — every Monday at 09:00 Berlin time
0 9 * * 1 www-data /var/www/myapp/bin/send-digest.sh

# Nightly DB backup — every day at 02:00
0 2 * * * www-data /var/www/myapp/bin/backup.sh >> /var/log/backup.log 2>&1

# 15-minute health sweep
*/15 * * * * www-data /var/www/myapp/bin/health-check.sh

El manifiesto equivalente de SteadyCron

namespace: myapp

channels:
  - id: team-email
    kind: email
    email: oncall@myapp.com

jobs:
  # Job HTTP: SteadyCron llama directamente al endpoint.
  # Reintenta en caso de fallo; alerta por el canal si sigue fallando.
  - id: weekly-digest
    name: Weekly digest email
    kind: http
    method: POST
    url: https://api.myapp.com/jobs/send-digest
    schedule: "0 9 * * 1"
    timezone: Europe/Berlin
    timeout: 120
    retries: 3
    channel: team-email

  # Heartbeat: el script de backup hace ping a SteadyCron al completarse.
  # SteadyCron alerta si el ping no llega o llega tarde.
  - id: nightly-backup
    name: Nightly DB backup
    kind: heartbeat
    schedule: "0 2 * * *"
    grace: 1800
    channel: team-email

  # Heartbeat: el script de health check hace ping tras cada ejecución.
  - id: health-sweep
    name: 15-minute health sweep
    kind: heartbeat
    schedule: "*/15 * * * *"
    grace: 120
    channel: team-email

Reglas de asignación

Concepto de crontab	Equivalente en SteadyCron
Expresión de calendario	schedule — misma sintaxis cron de 5 campos
MAILTO="" (suprimir correo)	Eliminar el campo channel (sin alertas)
Zona horaria mediante variable TZ=	Campo timezone por job
Script que llama a un endpoint	Job kind: http
Script que usted controla (se ejecuta en su servidor)	kind: heartbeat — el script hace ping a SteadyCron al tener éxito
Redirección a archivo de log	SteadyCron almacena logs completos de solicitud/respuesta; no es necesaria la redirección
2>&1 (capturar stderr)	SteadyCron captura tanto el estado como el cuerpo de las respuestas HTTP

Job HTTP vs heartbeat: ¿cuál usar?

Use kind: http cuando su lógica de cron está detrás de un endpoint HTTP que usted controla. SteadyCron lo llama según el calendario, gestiona los reintentos, registra la respuesta y alerta ante fallos. Su entrada de crontab y el script de shell dejan de ser necesarios — el endpoint es el job.

Use kind: heartbeat cuando:

• El script se ejecuta directamente en un servidor (shell, Python, PHP, etc.)
• No puede o no quiere exponer un endpoint HTTP
• El script ya existe y solo quiere monitorizarlo

Para los heartbeats, añada una única llamada curl a la URL de ping de SteadyCron al final de su script:

#!/bin/bash
set -euo pipefail

# ... su lógica de backup ...

# Señalar éxito a SteadyCron
curl -fsS https://ping.steadycron.com/{your-token}

Consulte Ping desde cualquier lenguaje para snippets en Python, Ruby, PHP, Node.js y más.

Qué se gana

	crontab	SteadyCron
Alertas ante fallos	No	Sí — email, Slack, Discord, Telegram, webhook
Alertas ante ejecución perdida	No	Sí — con grace period configurable
Reintentos	No	Sí — configurables por job
Timeout forzado	No	Sí — por job
Log de ejecución	No (rotación de logs)	Sí — historial completo de solicitud/respuesta
Control de versiones	No fácilmente	Sí — el manifiesto vive en su repositorio
Zona horaria por job	Con trucos de TZ=	Campo nativo timezone
Revisión de PR para cambios	No	Sí — steadycron plan en CI

Próximos pasos

1. Aplique el manifiesto: steadycron sync manifests/myapp.yaml
2. Para jobs de heartbeat: añada la URL de ping a sus scripts
3. Configure CI para revisar cambios: Configuración CI/CD
4. Para jobs existentes del dashboard: Migrar a IaC