Zeitplan · Ausführung
Ihre Endpunkte, aufgerufen
nach Plan.
Wir rufen Ihren Endpunkt planmäßig auf; Sie kümmern sich um den Handler. Ein echter Request Builder — kein URL-Feld — mit Wiederholungen, Timeout-Durchsetzung und einem vollständigen Ausführungsprotokoll für jeden Lauf.
Kostenloser Tarif — keine Kreditkarte erforderlich.
Ohne 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.Mit SteadyCron
✓ nach 1 Wiederholung wiederhergestellt — bei Fehler alarmiert, bei Wiederherstellung aufgelöst
Das Problem
System-Cron ist eine Lüge, die Sie akzeptiert haben
Er feuert und vergisst. Keine Wiederholungen. Keine Timeouts. Kein Auditprotokoll. Keine Alarme, wenn das Skript fehlschlägt, das Timeout überschreitet oder ganz aufhört zu laufen.
Stille Ausfälle
Ihr Cron feuert, Ihr Skript stürzt ab, niemand merkt es. Das DB-Backup, das seit sechs Wochen nicht mehr läuft. Der Bericht, der seit dem Deployment leer ist.
exit 1 # ← zero alerts Keine Wiederholungen oder Timeouts
Ein kurzer Netzwerkausfall schlägt den Job dauerhaft fehl. Oder ein Job hängt unbegrenzt, belegt einen Cron-Slot, während der Speicher des Servers steigt.
SIGKILL? never heard of it Grauenhafte Cron-Syntax
Jedes Team hat ein README mit einer Legende dafür, was 0 4 * * 1 bedeutet. Dann bearbeitet jemand es falsch und der Job läuft jede Minute um 4 Uhr.
0 4 * * 1 # ??? Kein Auditprotokoll
"Lief der Invoice-Job letzten Dienstag?" Sie prüfen die Logs. Es gibt keine Logs. cron.log wurde vor sechs Tagen rotiert.
grep -i invoice /var/log/cron.log So funktioniert es
Einmal definieren. Läuft für immer.
Kein Cron-Daemon zu betreuen. Keine Log-Rotation zu beachten. SteadyCron übernimmt die Ausführung — von Anfang bis Ende.
Job definieren
URL, Methode, Header, Body, Zeitplan und Zeitzone in zwei Minuten einstellen. Wiederholungen, Timeout und Template-Variablen hinzufügen. Oder als Code deklarieren und aus CI anwenden.
POST /v1/invoices/send 0 9 * * 1-5 Europe/Berlin Wir senden den Request
Zum geplanten Zeitpunkt sendet SteadyCron den HTTP-Request mit Ihren genauen Headern und dem Body. DST wird korrekt behandelt. Wenn der Antwort-Statuscode einen Retry auslöst, wiederholen wir mit exponentiellem Backoff.
POST → 200 OK 312ms attempt 1/1 Jede Ausführung inspizieren
Jeder Lauf wird protokolliert: Antwortstatus, Body, Header, Dauer und Versuchsnummer. Ein Lauf, der fehlschlug und bei einem Retry wiederhergestellt wurde, sieht anders aus als einer, der alle Versuche erschöpft hat.
→ success attempt 2/3 847ms total Request Builder
Ein echter Request Builder,
kein URL-Feld
Beginnen Sie mit einem Namen, einer URL und einem Zeitplan. Wählen Sie Cron-Ausdruck oder Intervall — eine Live-Vorschau der nächsten Läufe zeigt Ihnen die genauen Ausführungszeiten, bevor Sie speichern — keine Überraschungen um 3 Uhr morgens.
Wählen Sie eine beliebige HTTP-Methode. Fügen Sie Request-Header hinzu — Authorization, Content-Type oder alles, was Ihr Endpunkt erwartet. Hängen Sie einen JSON-Body für POST- und PUT-Jobs an, mit Live-Syntaxhervorhebung und Validierung, die fehlerhafte Payloads abfängt, bevor sie ausgeliefert werden.
Für die fortgeschrittenen Fälle: Fügen Sie {{template}} Variablen an beliebiger Stelle in URL, Headern oder Body ein. Sie werden serverseitig zum Ausführungszeitpunkt aufgelöst und nie in Ihren Skripten gespeichert — nützlich für API-Tokens, Account-IDs oder jeden Wert, der über Umgebungen hinweg variiert. Zeitplan pro Job in Ihrer Zeitzone bedeutet: "Werktags um 09:00 Berlin" läuft um 09:00 Berlin, auch über DST-Übergänge hinweg.
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
Was wir erfassen
Vier mögliche Ausführungsergebnisse
Jedes Ergebnis ist eindeutig, protokolliert und im Dashboard mit eigener Farbe und Bezeichnung angezeigt.
Erfolg
Der Endpunkt gab eine 2xx-Antwort innerhalb des konfigurierten Timeouts zurück. Ausführung abgeschlossen, vollständige Antwort protokolliert.
Fehler
Der Endpunkt gab bei allen Versuchen einen Nicht-2xx-Status zurück, oder die Verbindung schlug fehl. Jeder Versuch ist ein separater Protokolleintrag.
Timeout
Der Endpunkt antwortete nicht innerhalb des jobspezifischen Timeouts. Der Request wird sauber abgebrochen — keine Zombie-Verbindungen.
Übersprungen
Der vorherige Lauf war noch in Bearbeitung, als dieser Auslöser fällig war. Der Überlappungsschutz verhinderte eine gleichzeitige Ausführung.
Zuverlässigkeit
Entwickelt für Jobs, die nicht still ausfallen dürfen
Die Steuerungselemente, die Sie sonst manuell rund um System-Cron implementieren würden, sind hier erstklassige Konfiguration.
Wiederholungen mit exponentiellem Backoff
Konfigurieren Sie bis zu 5 Wiederholungen mit exponentiellem Backoff. Legen Sie genau fest, welche HTTP-Statuscodes einen Retry auslösen — so bleibt ein 404 ein harter Fehler, aber ein 503 bekommt eine weitere Chance.
retry_on: [429, 503, 502]
max_retries: 3 backoff: 30s Jobspezifische Timeout-Durchsetzung
Wenn Ihr Endpunkt hängt — langsame DB-Abfrage, vorgelagerte API degradiert — bricht SteadyCron den Request nach dem konfigurierten Timeout ab. Keine Zombie-Verbindungen, keine stillen Ressourcenlecks.
timeout_seconds: 30
# error_kind: request_timeout Überlappungsschutz
Wenn der vorherige Lauf noch nicht abgeschlossen ist, wenn der nächste Auslöser fällig ist, überspringen wir den neuen Lauf, anstatt gleichzeitige Requests gegen Ihren Endpunkt zu stapeln. Verhindert Thundering-Herd-Ausfälle bei langsamen Jobs.
skip_if_still_running: true
# status: skipped Auditprotokoll
Jeder Lauf, vollständig protokolliert
Antwortstatus, Body, Header, Dauer und Versuchsnummer — für jede Ausführung gespeichert. Nie wieder "Lief der Invoice-Job letzten Dienstag?" fragen und ein Achselzucken erhalten.
Fehlgeschlagene Läufe, die bei einem Retry wiederhergestellt wurden, sehen anders aus als Läufe, die alle Versuche erschöpft haben. Jeder Versuch ist ein eigener Protokolleintrag mit eigenem Timing und Statuscode, sodass Sie genau sehen können, wo etwas schief gelaufen ist.
invoice-send · Ausführungsprotokoll
Eine Plattform, drei Aufgaben
HTTP-Ausführung
Sie sind hierEndpunkte planmäßig aufrufen — Wiederholungen, Timeouts und vollständige Laufprotokolle.
Heartbeat-Monitoring
Überwachen Sie Jobs, die Sie überall betreiben — Alarm, sobald einer verstummt.
Cron as Code
Jeden Job, Monitor und Alert in YAML oder Terraform definieren.
Hören Sie auf zu rätseln, ob Ihr Job lief.
Definieren Sie den Job einmal. Wir übernehmen Ausführung, Wiederholungen, Timeouts und Auditprotokoll. Sie kümmern sich um den Handler.
- Kostenloser Tarif — keine Kreditkarte
- EU-gehostet, DSGVO-konform
- 5 HTTP-Jobs im kostenlosen Tarif