Cron as Code

Cron como código,
de principio a fin

Q: ¿Mis claves API o secretos se almacenan alguna vez como código?

No. En el manifiesto, los placeholders ${ENV_VAR} son sustituidos por la CLI en el momento de aplicar, y los valores {{template_var}} se resuelven en el servidor durante la ejecución — steadycron export genera ambos automáticamente. En Terraform, los secretos se declaran como variables sensitive y se proporcionan al aplicar.

Q: ¿Qué pasa con mi ping URL de heartbeat si renombro un job?

Nada cambia. La ping URL de cada job está vinculada a su id / key estable, no a su nombre visible — así que renombrar es solo eso, y tus scripts y referencias del SDK siguen funcionando.

Declara cada job, monitor, canal y regla de alerta en YAML o Terraform. Revisa los cambios en pull requests, aplícalos desde GitHub Actions, y observa la ejecución desde dentro de tu app con los SDK de .NET y Python — todo desde un único repositorio.

Empezar gratis Leer la documentación

Plan gratuito — sin tarjeta de crédito.

1
Declarar

Declara jobs, monitores, canales y reglas.

YAMLTerraform
2
Reconciliar

validate → plan → apply. Sin desviaciones.

CLIProvider
3
Desplegar

Plan en cada PR, apply al hacer merge.

GitHub Actions
4
Observar

Observa la ejecución desde tu app.

.NETPython

1 · Declarar

Elige tu dialecto.
Mismo resultado.

Un único archivo declara toda tu cuenta — jobs HTTP, monitores heartbeat, canales de alerta, reglas, tags y variables. Escríbelo como un manifiesto YAML o como HCL de Terraform; ambos expresan los mismos recursos y reconcilian de la misma manera.

Usa el manifiesto si quieres un único archivo autocontenido. Recurre a Terraform si el cron debe vivir junto al resto de tu infraestructura. La paridad es la cuestión clave — ninguno de los dos es un ciudadano de segunda clase.

Referencia del manifiesto Provider de Terraform

# steadycron.yaml — your whole account as code
version: 2
namespace: prod

channels:
  - id: ops-slack
    kind: slack
    config:
      webhook_url: ${SLACK_WEBHOOK_URL}

jobs:
  - id: weekly-digest
    kind: http
    method: POST
    url: https://api.myapp.com/jobs/digest
    schedule: "0 9 * * 1"
    timezone: Europe/Berlin
    timeout: 120
    retries: 3
    rules:
      - channel: ops-slack
        trigger: on_failure

  - id: nightly-db-backup
    kind: heartbeat
    schedule: "0 2 * * *"
    grace: 1800

# main.tf — the same account, in HCL
resource "steadycron_alert_channel" "ops_slack" {
  name              = "ops-slack"
  kind              = "slack"
  slack_webhook_url = var.slack_webhook_url
}

resource "steadycron_http_job" "weekly_digest" {
  name            = "weekly-digest"
  method          = "POST"
  url             = "https://api.myapp.com/jobs/digest"
  cron_expression = "0 9 * * 1"
  timezone        = "Europe/Berlin"
  timeout_seconds = 120
  max_retries     = 3
}

resource "steadycron_alert_rule" "digest_failure" {
  job_id     = steadycron_http_job.weekly_digest.id
  channel_id = steadycron_alert_channel.ops_slack.id
  trigger    = "on_failure"
}

resource "steadycron_heartbeat_monitor" "db_backup" {
  name            = "nightly-db-backup"
  key             = "nightly-db-backup"
  cron_expression = "0 2 * * *"
  grace_seconds   = 1800
}

Terminal

$ steadycron validate steadycron.yaml
✓ 2 jobs · 1 channel · 1 rule — no errors

$ steadycron plan steadycron.yaml --namespace prod
  ~ weekly-digest      update     retries: 2 → 3
  + nightly-db-backup  create     heartbeat · 0 2 * * *
  1 to update · 1 to create

$ steadycron sync steadycron.yaml --namespace prod
✓ applied — account now matches the manifest

2 · Reconciliar

validate → plan → apply. Sin sorpresas.

La CLI steadycron reconcilia tu cuenta para que coincida con el manifiesto. plan muestra exactamente qué cambiaría, sync lo aplica de forma transaccional, y --prune elimina lo que has quitado — acotado a un namespace para que el radio de impacto sea siempre explícito.

→export adopta una cuenta existente en un manifiesto en segundos.
→import crontab / import vercel migran horarios existentes.
→¿Usas Terraform? terraform plan / apply / import impulsan exactamente el mismo ciclo.

Flujo de trabajo CLI e IaC

3 · Desplegar

Plan en cada PR. Apply al hacer merge.

La GitHub Action steadycron/action@v1 publica un comentario de plan persistente en cada pull request — los revisores ven exactamente qué jobs, monitores, canales y reglas introduce un cambio — y luego lo aplica al hacer merge. Tu rama principal es la fuente de verdad.

La misma action gestiona ambas herramientas: define tool: yaml para manifiestos o tool: terraform para HCL.

Configuración de CI/CD

steadycron bot comentó en este PR

Plan: 1 actualización · 1 creación · 1 eliminación

~ weekly-digest      update   retries: 2 → 3
+ invoice-reminder   create   http · 0 17 * * 5
- old-report         delete   (removed from manifest)

# .github/workflows/cron.yml
- uses: steadycron/action@v1
  with:
    command: plan          # 'apply' on merge to main
    manifest: steadycron.yaml
    comment-on-pr: "true"
  env:
    STEADYCRON_API_KEY: ${{ secrets.STEADYCRON_API_KEY }}

4 · Observar

El job y el código que lo observa — mismo key, mismo repositorio.

Declara un monitor heartbeat con un key estable en YAML o Terraform. Referencia ese mismo key desde tu aplicación con el SDK de .NET o Python. SteadyCron entonces sabe cuándo el job comenzó, tuvo éxito, falló, o nunca se ejecutó.

Los SDK nunca crean monitores — resuelven el key con una clave API de solo lectura, y los pings son fire-and-forget: una caída de la monitorización nunca derriba tu job. Horario, reglas de alerta e instrumentación viven juntos, como código.

SDK de Python SDK de .NET Monitorización heartbeat

En tu manifiesto / HCL

key: nightly-db-backup

import steadycron

@steadycron.job("nightly-db-backup")   # same key
def backup():
    run_backup()   # start · success · fail — automatic

// same key as the manifest
await monitor.TrackAsync("nightly-db-backup", async ct =>
{
    await RunBackupAsync(ct);
});

Todo el ciclo como código

Horario, monitorización, enrutamiento de alertas y la instrumentación dentro de la app — un repositorio, una revisión, un despliegue.

Alojado en la UE, nativo de RGPD

Se ejecuta en Hetzner en Alemania, regido por la ley alemana. Sin subencargados estadounidenses para la ejecución de cron o los datos de los jobs.

Herramientas que ya usas

YAML o Terraform, una CLI dedicada, una GitHub Action y SDK propios — sin un DSL a medida, sin dependencia de una consola.

Preguntas frecuentes

Preguntas comunes

¿Manifiesto YAML o Terraform — cuál debería usar?

El que tu equipo ya haya estandarizado. El manifiesto YAML con la CLI steadycron es autocontenido y no necesita más herramientas; el provider de Terraform encaja de forma natural si ya usas Terraform. Ambos expresan los mismos recursos y comparten el mismo ciclo plan / apply / import. Gestiona un recurso dado con una sola herramienta, no con ambas.

¿Puedo usar esto en mi pipeline de CI/CD?

Sí — ese es el flujo de trabajo recomendado. La GitHub Action steadycron/action@v1 ejecuta plan en los pull requests (publicando un comentario persistente) y apply al hacer merge — tanto para YAML (tool: yaml) como para Terraform (tool: terraform). Consulta la guía de configuración de CI/CD.

¿Los SDK de .NET y Python crean los monitores?

No. Los SDK solo envían pings — resuelven un monitor por su key estable usando una clave API de solo lectura. Declara primero el monitor heartbeat en YAML o Terraform, y luego referencia ese mismo key desde el código de tu aplicación.

¿Mis claves API o secretos se almacenan alguna vez como código?

No. En el manifiesto, los placeholders ${ENV_VAR} son sustituidos por la CLI en el momento de aplicar, y los valores {{template_var}} se resuelven en el servidor durante la ejecución — steadycron export genera ambos automáticamente. En Terraform, los secretos se declaran como variables sensitive y se proporcionan al aplicar.

¿Gestionar los jobs como código sustituye al dashboard?

No. Los namespaces permiten que los jobs gestionados por código y los creados en el dashboard coexistan en una misma cuenta. Solo los recursos dentro del namespace de tu manifiesto son afectados por --prune — todo lo demás permanece intacto.

¿Qué pasa con mi ping URL de heartbeat si renombro un job?

Nada cambia. La ping URL de cada job está vinculada a su id / key estable, no a su nombre visible — así que renombrar es solo eso, y tus scripts y referencias del SDK siguen funcionando.

Una plataforma, tres trabajos

Ejecución HTTP

Llama a tus endpoints según el horario — reintentos, tiempos de espera y logs completos.

Monitorización heartbeat

Vigila los jobs que ejecutas donde sea; recibe alerta en cuanto uno se silencia.

Cron as code

Estás aquí

Define cada job, monitor y alerta en YAML o Terraform.

Cron jobs que viven en tu repositorio

Regístrate, exporta tu cuenta actual, y haz commit de tu primer manifiesto en minutos — en YAML o en Terraform.

Empezar gratis Leer la documentación

Plan gratuito — sin tarjeta de crédito
YAML o Terraform — soporte equivalente
Alojado en la UE, nativo de RGPD

Cron como código,de principio a fin

Declarar

Reconciliar

Desplegar

Observar

Elige tu dialecto.Mismo resultado.