Schedule · Run
Your endpoints, called
on schedule.
We call your endpoint on schedule; you focus on the handler. A real request builder — not a URL box — with retries, timeout enforcement, and a full execution log for every run.
Free tier — no credit card required.
Without SteadyCron
# /etc/cron.d/invoices
0 9 * * 1-5 deploy /app/send_invoices.sh
# Exit code: unknown.
# Retries: none.
# Logs: rotated.
# Did it run? Check manually.With SteadyCron
✓ recovered after 1 retry — alerted on failure, resolved on recovery
The problem
System cron is a lie you've accepted
It fires and forgets. No retries. No timeouts. No audit log. No alerts when the script fails, times out, or stops running entirely.
Silent failures
Your cron fires, your script crashes, nobody notices. The DB backup that hasn't run in six weeks. The report that's been empty since the deploy.
exit 1 # ← zero alerts No retries or timeouts
A transient network hiccup fails the job permanently. Or a job hangs indefinitely, eating a cron slot while the server memory climbs.
SIGKILL? never heard of it Awful cron syntax
Every team has a README with a legend for what 0 4 * * 1 means. Then someone edits it wrong and the job runs at 4 AM every minute.
0 4 * * 1 # ??? No audit trail
"Did the invoice job run last Tuesday?" You check the logs. There are no logs. cron.log was rotated six days ago.
grep -i invoice /var/log/cron.log How it works
Define once. Runs forever.
No cron daemon to babysit. No log rotation to worry about. SteadyCron owns the execution — start to finish.
Define the job
Set the URL, method, headers, body, schedule, and timezone in two minutes. Add retries, a timeout, and template variables. Or declare it as code and apply from CI.
POST /v1/invoices/send 0 9 * * 1-5 Europe/Berlin We fire the request
At the scheduled time, SteadyCron sends the HTTP request with your exact headers and body. DST is handled correctly. If the response is a retryable status code, we retry with exponential backoff.
POST → 200 OK 312ms attempt 1/1 Inspect every execution
Every run is logged: response status, body, headers, duration, and attempt number. A run that failed then recovered on retry looks different from one that exhausted all attempts.
→ success attempt 2/3 847ms total Request builder
A real request builder,
not a URL box
Start with a name, a URL, and a schedule. Pick cron expression or interval — a live "next runs" preview shows you the exact fire times before you save, so there are no surprises at 3 AM.
Choose any HTTP method. Add request headers — Authorization, Content-Type, or anything your endpoint expects. Attach a JSON body for POST and PUT jobs, with live syntax highlighting and validation that catches malformed payloads before they ship.
For the advanced cases: drop {{template}} variables anywhere in the URL, headers, or body. They're resolved server-side at fire time and never stored in your scripts — useful for API tokens, account IDs, or any value that varies across environments. Per-job timezone scheduling means "weekdays at 09:00 Berlin" runs at 09:00 Berlin, even across DST transitions.
Request
Configure the HTTP request sent on each execution. Use
{{variable}}
for template substitution.
Headers
{
"account_id": "{{accountId}}",
"amount_cents": 4900,
"send_email": true
}✓ Valid JSON
Schedule
When it runs — cron or interval, with DST-correct timezones and a live next-runs preview.
Cron expression
Weekdays at 09:00
Timezone
Next runs
What we track
Four ways an execution can land
Each outcome is distinct, logged, and surfaced in the dashboard with its own colour and label.
Success
The endpoint returned a 2xx response within the configured timeout. Execution complete, full response logged.
Failure
The endpoint returned a non-2xx status on all attempts, or the connection failed. Every attempt is a separate log entry.
Timeout
The endpoint did not respond within the per-job timeout. The request is aborted cleanly — no zombie connections.
Skipped
The previous run was still in progress when this fire was due. The overlap guard prevented a concurrent execution.
Reliability
Built for jobs that must not fail silently
The controls you'd otherwise hand-roll around system cron are first-class configuration here.
Retries with exponential backoff
Configure up to 5 retries with exponential backoff. Choose exactly which HTTP status codes trigger a retry — so a 404 stays a hard failure but a 503 gets another chance.
retry_on: [429, 503, 502]
max_retries: 3 backoff: 30s Per-job timeout enforcement
If your endpoint hangs — slow DB query, upstream API degraded — SteadyCron aborts the request after the configured timeout. No zombie connections, no silent resource leaks.
timeout_seconds: 30
# error_kind: request_timeout Overlap guard
If the previous run hasn't finished when the next fire is due, we skip the new run rather than stacking concurrent requests against your endpoint. Prevents thundering-herd failures on slow jobs.
skip_if_still_running: true
# status: skipped Audit trail
Every run, logged in full
Response status, body, headers, duration, and attempt number — stored for every execution. Never again ask "did the invoice job run last Tuesday?" and get a shrug.
Failed runs that recovered on a retry look different from runs that exhausted all attempts. Each attempt is its own log entry with its own timing and status code, so you can see exactly where things went wrong.
invoice-send · execution log
One platform, three jobs
HTTP Execution
You're hereRun your endpoints on schedule — retries, timeouts, and full run logs.
Heartbeat Monitoring
Watch jobs you run anywhere; get alerted the moment one goes silent.
Cron as Code
Define every job, monitor, and alert in YAML or Terraform.
Stop wondering if your job ran.
Define the job once. We handle the execution, retries, timeouts, and audit trail. You handle the handler.
- Free tier — no credit card
- EU-hosted, GDPR-native
- 5 HTTP jobs on the free plan