Ein E-Commerce-Unternehmen stellt an einem Montag fest, dass seit zwölf Tagen keine Bestellungen in das ERP exportiert wurden. Das Cron-Skript wird ausgeführt: korrekter Crontab-Eintrag, Protokolldatei vom heutigen Morgen. In Wirklichkeit schlägt der Job bei der SFTP-Verbindung seit einer Schlüsseländerung fehl – aber der Entwickler hat stderr nicht umgeleitet, niemand überwacht den Exit-Code und die Freigabe führt keine Benachrichtigung durch.
Cron-Jobs sind von Natur aus unsichtbar. Sie laufen nachts, ohne dass ein Benutzer vor dem Bildschirm sitzt. Genau aus diesem Grund erfordern sie mehr Beobachtbarkeit als eine Webseite – nicht weniger.
Anatomie eines Produktions-Crons
| Element | Schlechte Praxis | Gute Praxis |
|---|---|---|
| Ausstieg | /dev/null | Strukturiertes Protokoll + Rotation |
| Fehler | Ignoriert | Warnung, wenn Exit ≠ 0 |
| Dauer | Nicht gemessen | Timeout + Überlaufalarm |
| Wettbewerb | Doppelte Ausführung | Flocksperre / Redis |
| Idempotenz | Nein | Wiederspielbar ohne Doppeleffekt |
Ein Cron, der ohne Nachweis des Geschäftserfolgs „läuft“, ist nicht gelaufen – er hat nur CPU verbraucht.
Geteilt vs. VPS: Wohin verschlägt es Ihnen?
Geteilt:
- Geringe Zeitgenauigkeit; Überschneidungen mit benachbarten Arbeitsplätzen.
- Cron „mail()“ oft deaktiviert oder Spam-gefiltert.
- Kein erweiterter System-Timer.
VPS / Cloud:
- systemd-Timer mit „Persistent=true“ (Aufholen verpasst).
- Zentralisierte Journalprotokolle.
- Engagierte Arbeitskräfte für schwere Arbeiten.
Für die Synchronisierung von Rechnungen oder Lagerbeständen ist die gemeinsame Nutzung ein Glücksspiel. Für wöchentliches Cache-Löschen akzeptabel.
Minimales Beobachtbarkeitsmuster
- Hülle:
„Bash #!/bin/bash set -euo pipefail LOG=/var/log/jobs/export-erp.log { echo "=== $(date -Is) start ===" /usr/bin/php /app/bin/export-erp.php echo "=== $(date -Is) ok ===" } >> "$LOG" 2>&1 || curl -fsS -m 10 --retry 3 https://hc.example/ping/xxx-fail
2. **Healthchecks.io / Cronitor** – START und SUCCESS anpingen; Alarm bei Abwesenheit.
3. **Dauermetrik** – Grafana oder einfaches geparstes Protokoll; Alarm, wenn > 2× Median.
4. **Runbook** – Link in der Warnung zum manuellen Verfahren.
Siehe [Crontab und Sperren](/de/blog/crontab-verrouillage/) und [Celery: Verhindern, dass eine Aufgabenwarteschlange zu einer Blackbox wird](/de/blog/celery-files-attente/).
## Idempotenz und Sperren
Klassisches Szenario: Produktimport dauert 25 Minuten, Cron alle 15 Minuten → **zwei Importe** beschädigen die Datenbank.
Lösungen:
- **flock -n** am Anfang des Skripts – überspringen, wenn es bereits ausgeführt wird.
– **Redis SET NX** mit TTL > maximale Jobdauer.
- **PostgreSQL-Beratungssperre** für DB-zentrierte Jobs.
Jeder kritische Job muss **wiederholbar** sein: Neustart ohne Verdoppelung der Schreibvorgänge (UPSERT, Batch_ID-Marker).
## Cron-Migration → Warteschlange
| Signal | Aktion |
| --- | --- |
| Auftrag > 5 Min. | Arbeiter + Schwanz |
| Mit Backoff erneut versuchen | Sellerie / Messenger |
| Abhängigkeiten zwischen Jobs | Orchestrator (Zeitlich, Luftstromlicht) |
| Sichtbarkeit des Teams | Armaturenbrett Blume / Horizont |
Der Cron ist immer noch nützlich zum **Triggern** (`0 2 * * * php bin/console Messenger:consume`) – nicht zum Inline-Laufen.
## Der Gipfel: Cron-Fehler werden immer vom Fachmann entdeckt, niemals von der Technik
:::Höhepunkt
**An einem ruhigen Dienstag überprüft niemand die Cron-Protokolle. Jeder überprüft die Buchhaltung, wenn keine Zahlen eingehen.** Ein Auftrag ohne externe Benachrichtigung existiert für die Organisation nicht – bis ein Kunde anruft.
:::
Der Host verkauft „Cron inklusive“. Ihre Verantwortung: **Nachweis von Erfolg oder Misserfolg** unabhängig vom Panel-Hosting.
## Entscheide dich und gehe ohne blinden Fleck voran
1. **Inventarisierung aller Crons** (Crontab + Panel + CI).
2. **Kritikalität klassifizieren** und externen Gesundheitscheck zu Bewertungen hinzufügen.
3. **Sperren** Jobs > 1 Minute oder kurzes Intervall.
4. **Testfehler** freiwillig – Warnung kommt in < 5 Minuten?
5. **Dokument**-Besitzer und Runbook pro Auftrag.
Vergleichen Sie PaaS mit Observable Cron ([Alwaysdata](/de/anbieter/alwaysdata/)) über unser [Verzeichnis](/de/verzeichnis/).
## Häufig gestellte Fragen
### Warum sind geteilte Crons unzuverlässig?
Ungenaue Fenster, gemeinsame Last, keine Fehlerbenachrichtigung – riskant für kritische Synchronisierung.
### Woher weiß ich, ob ein Cron fehlgeschlagen ist?
Protokollierter Exit-Code + externer Ping oder Alarm; Schweigen ist kein Erfolg.
### Ist eine Sperre erforderlich, um Duplikate zu vermeiden?
Ja, wenn Jobdauer ≥ Intervall – Flock, Redis oder Beratungssperre.
### System-Cron oder Warteschlange?
Cron für kurz und selten; Warteschlange + Worker für Long, Retry und Sichtbarkeit.
---
Ein zuverlässiger Cron wird nachts nicht gesehen – er wird morgens nachgewiesen oder alarmiert, bevor das Unternehmen ihn bemerkt.