Cron jobs as code.
Finally.

Everything runs on Hetzner infrastructure in Germany, governed by German law. Core execution uses no US sub-processors, and a GDPR DPA is available.

Yes. Add a heartbeat check and have your job send a ping when it finishes (a single curl at the end of your script). If the ping doesn't arrive on schedule, SteadyCron alerts you. It works from any language or shell.

For scheduled HTTP work, yes. SteadyCron calls your endpoint on schedule with configurable retries, timeouts, and full request/response logs — without locking you into one cloud. You also get monitoring and alerting in the same place.

Yes — the official provider is published as steadycron/steadycron on the Terraform Registry. It manages HTTP jobs, heartbeat monitors, alert channels, alert rules, tags, and template variables as HCL resources with full plan / apply / import support. Requires Terraform ≥ 1.0 and a Full-scope API key. Resources managed via Terraform live alongside manifest-managed ones — SteadyCron never prunes Terraform resources during a steadycron sync --prune.

SteadyCron retries failed requests with configurable exponential backoff — and only on the HTTP status codes you choose. Per-job timeouts prevent indefinitely hanging runs, and each execution is fully logged with the response status, body, and duration. If retries are exhausted, an alert fires via your configured channel.

A heartbeat monitor watches a cron job you already run — on your own server, a container, a GitHub Actions workflow, or anywhere else. Your script sends a ping to a unique URL at the end of each successful run. If the ping doesn't arrive within the expected window, SteadyCron raises an alert. It takes one extra line: curl -s https://ping.steadycron.com/hb/<id>.

Create an alert rule on any job or heartbeat monitor, pick the trigger that matters — on failure, after N consecutive failures, when a heartbeat is missed, or when the job recovers — and attach it to a channel (email, Slack, Discord, Telegram, or webhook). Alerts auto-resolve when the job returns to healthy, so nothing needs to be manually cleared.

Yes. Beyond standard failure triggers, SteadyCron offers two anomaly-detection triggers: Slow run fires when a job's execution time exceeds a configurable multiple of its own median — useful for catching jobs that are technically succeeding but taking far longer than usual. Response size anomaly fires when the payload deviates significantly from the baseline, which can surface silent data issues without any code changes.

Flapping happens when a job rapidly alternates between healthy and failing, generating a flood of alerts. SteadyCron's flapping guard detects this pattern and suppresses the noise, sending a single Flapping started notice instead. Once the job stabilises you get a Flapping resolved notice. Every suppressed delivery is still logged with its reason, so nothing is hidden.

Yes. HTTP job execution works with any endpoint regardless of the stack behind it. Heartbeat monitoring is equally language-agnostic — any script, cron, or worker that can make an HTTP request (shell, Python, Ruby, Go, Node, PHP…) can ping a heartbeat URL. No agents or SDKs to install.

Most online cron runners only execute jobs; most monitoring tools only watch them. SteadyCron does both in one place, so execution logs, heartbeat history, and alert history all live together. On top of that, SteadyCron is the only cron platform with a first-class infrastructure-as-code workflow: a Terraform provider, a YAML manifest with validate/plan/apply, and a native GitHub Action. It's also EU-hosted with a signed DPA — the natural choice for teams with data-residency requirements. See the full comparison →