Container

Eine Docker-Cron-Alternative, die auch Kubernetes-CronJobs überwacht

Hören Sie auf, Cron-Daemons in Containern zu betreiben. Lassen Sie SteadyCron Ihre Jobs von außen aufrufen — oder behalten Sie Ihr bestehendes Docker-/K8s-Cron und überwachen Sie es einfach mit einem Heartbeat.

Kostenlos starten Zur Dokumentation

Das Problem

Cron in einem Container ist eine wiederkehrende Quelle von Problemen: Der Daemon braucht eine eigene Prozessüberwachung in einem sonst Single-Process-Image, Logs landen im Container-Stdout statt in Ihrem Aggregator gefangen, und die Zeitzone des Containers driftet leise von dem ab, was Sie erwarten. Kubernetes-CronJobs lösen das Daemon-Problem, aber nicht das Sichtbarkeitsproblem — ein CronJob, der leise aufhört, Pods zu erzeugen (ein pausierter Zeitplan, ein schlechtes Image, ein ausgeschöpftes Backoff-Limit), scheitert vollkommen lautlos. Nichts in kubectl sagt Ihnen, dass ein Job vor einer Stunde hätte laufen sollen.

So löst SteadyCron das

  1. 1 Option A — den Trigger ganz aus dem Container herausnehmen: Stellen Sie einen einfachen HTTP-Endpunkt in Ihrer App bereit und lassen Sie SteadyCron ihn planmäßig mit Wiederholungen und Timeout aufrufen. Kein Cron-Daemon, kein zusätzlicher Prozess, keine Zeitzonen-Überraschungen im Image.
  2. 2 Option B — Ihr bestehendes Docker-Cron oder Kubernetes-CronJob behalten und einen Heartbeat ergänzen: Der Job pingt SteadyCrons Ping-URL bei Erfolg (oder /fail bei Fehler) als letzten Schritt an.
  3. 3 In beiden Fällen verfolgt SteadyCron erwartet vs. tatsächlich: Kommt der Ping (oder der HTTP-Aufruf) nicht innerhalb der gesetzten Kulanzzeit an, wechselt der Check von pünktlich zu verpasst.
  4. 4 Sie werden alarmiert, sobald ein CronJob aufhört zu feuern — nicht erst, wenn jemand merkt, dass der nächtliche Bericht fehlt. 
# Ergänzung zu einem bestehenden Kubernetes-CronJob: bei Erfolg pingen, bei verpasst/fehlgeschlagen alarmieren
command: ["/bin/sh", "-c"]
args:
  - >
    ./run-job.sh &&
    curl -fsS https://ping.steadycron.com/$PING_TOKEN ||
    curl -fsS https://ping.steadycron.com/$PING_TOKEN/fail
app.steadycron.com/jobs

Jobs

New job
Search jobs…
All HTTP Heartbeat
Status Group: env
env:prod 5 jobs 1 failing
weekly-digest-email HTTP 0 9 * * 1 in 2 days 3 days ago
nightly-db-backup Heartbeat 0 2 * * * in 19 h 5 h ago
stripe-reconciliation HTTP 0 */4 * * * in 38 min 3 h ago
cache-warmup HTTP */15 * * * * in 11 min now
search-index-sync Heartbeat */30 * * * * in 6 min 24 min ago
env:dev 3 jobs
seed-test-data HTTP 0 4 * * * in 14 h 10 h ago
preview-env-cleanup Heartbeat 0 */6 * * * in 2 h 4 h ago
trial-expiry-sweep HTTP 0 6 * * * — yesterday

Status, Zeitplan und letzter Lauf jedes Jobs — auf einen Blick.

Zwei Wege, Container-Cron zu beheben, je nachdem was Sie kontrollieren

Wenn Sie den App-Code besitzen: Lassen Sie das In-Container-Cron ganz weg. Fügen Sie einen HTTP-Endpunkt hinzu, der die Logik des Jobs ausführt, und lassen Sie SteadyCron ihn von außen nach Zeitplan aufrufen — mit eigenem Retry/Backoff und vollständigem Request-Log. Der Container kümmert sich wieder um nur einen Prozess, wie vorgesehen, und der Zeitplan liegt in SteadyCron statt in einer Crontab-Datei, die jeden Image-Rebuild überleben muss.

Wenn Sie den Trigger nicht anfassen wollen (ein Kubernetes-CronJob, den jemand anderes besitzt, ein Docker-Entrypoint, den Sie gerade nicht refaktorieren möchten): Lassen Sie ihn laufen und ergänzen Sie einen Heartbeat-Check. Ein curl am Ende des Skripts, und SteadyCron weiß, ob der Job gelaufen ist — und alarmiert Sie in dem Moment, in dem das nicht der Fall ist, statt dass Sie es über ein nachgeschaltetes Symptom erfahren.

Warum Container-Cron speziell so kaputtgeht

  • Docker: Ein Cron-Daemon in einem Container ist ein zweiter langlaufender Prozess, der mit der PID 1 konkurriert, die Ihr Orchestrator eigentlich überwacht. Stirbt der Daemon, sieht der Container weiterhin gesund aus — docker ps zeigt „läuft“ —, während intern nichts mehr feuert.
  • Kubernetes-CronJobs: Der Zeitplan selbst ist zuverlässig (der Controller ist Teil der Control Plane), aber Fehler sind by Design unsichtbar. Ein CronJob, der sein backoffLimit erreicht, ein zu enges startingDeadlineSeconds in einem ausgelasteten Cluster oder ein falscher Image-Tag — alle scheitern gleich: kein Pod, kein Fehler in Ihren Dashboards, nur ein Job, der leise aufgehört hat zu passieren.

Für die plattformspezifischen Details, falls Sie gerade live debuggen: Docker-Cron läuft nicht · Kubernetes-CronJob läuft nicht.

Gut geeignet für

  • Nächtliche Batch-Jobs, Backups und Report-Erstellung, die derzeit von einem in ein Docker-Image gebackenen Cron-Daemon ausgelöst werden.
  • Kubernetes-CronJobs für Cleanup-, Sync- oder Wartungsaufgaben, bei denen ein verpasster Lauf leicht übersehen wird, bis er sich aufsummiert.
  • Teams auf dem Weg zu einem Modell, bei dem der Zeitplan außerhalb des Containers liegt, damit Skalieren, Redeployen oder Cluster-Migrationen den Zeitplan nicht mitsamt dem Pod verlieren.

Verwandte Dokumentation

Erfahren Sie es nicht erst im Ernstfall

Starten Sie mit dem kostenlosen Tarif — keine Kreditkarte erforderlich.

Kostenlos starten