- Details
- Geschrieben von: Cronmanager Admin
- Kategorie: CronManager DE
- Zugriffe: 7
CronManager MCP-Server
Steuere CronManager über Claude Desktop oder Claude Code mit natürlicher Sprache. Der offizielle MCP-Server stellt 20+ Tools für Job-Verwaltung, Ausführungssteuerung und Wartungsfenster bereit — ohne manuelle Web-UI-Bedienung.
Was du damit tun kannst
Steuerung per Sprache
Claude fragen, fehlerhafte Jobs zu zeigen, einen Job zu deaktivieren, ein Wartungsfenster anzulegen oder einen Tag zu exportieren — und es passiert sofort, ohne die Web-UI zu öffnen.
20+ Tools
Vollständige Abdeckung: Jobs auflisten, erstellen, bearbeiten, löschen. Ausführungshistorie abrufen, Jobs starten, Ausführungen abbrechen. Wartungsfenster verwalten, Jobs exportieren, Einstellungen lesen und schreiben.
Sicher by Design
Der MCP-Server sitzt zwischen Claude und deiner CronManager-Instanz. Dein API-Key wird nie an Claude-Clients weitergegeben. Der MCP-Endpoint ist durch einen separaten Bearer Token geschützt.
Read-Only-Modus
Mit MCP_READONLY_MODE=true werden nur lesende Tools registriert — sicher für Claude-Zugriff ohne Änderungsrechte.
Multi-Agent-fähig
Optional CM_AGENT_ID setzen, um einen bestimmten CronManager-Agenten anzusprechen. Jobs auf verschiedenen Servern über eine einzige MCP-Server-Instanz verwalten.
Docker-Ready
Fertiges Image auf Docker Hub. In Minuten einsatzbereit — keine Node.js-Installation auf dem Host erforderlich.
Quick Start
In einem Befehl deployen
docker run -d \
-e CM_BASE_URL=https://cronmanager.example.com \
-e CM_API_KEY=cm_your_api_key_here \
-e MCP_AUTH_TOKEN=your_mcp_auth_token_here \
-p 3000:3000 \
cs1711/cronmanager-mcp:latestBenötigt einen CronManager API-Key (ab v4.1.0). Erstellen unter Einstellungen → API-Keys.
Beispiel-Prompts
Monitoring
„Zeige mir alle fehlgeschlagenen Jobs der letzten 24 Stunden"
„Welche Jobs liefen heute länger als 5 Minuten?"
Job-Steuerung
„Deaktiviere Job 42"
„Starte den Backup-Job jetzt und zeig mir die Ausgabe"
„Brich den hängenden Datenbankjob ab"
Wartung
„Erstelle ein Wartungsfenster für Sonntagsnacht um 2 Uhr, 2 Stunden lang"
„Liste alle aktiven Wartungsfenster auf"
Export & Einstellungen
„Exportiere alle Jobs mit Tag 'backup' als JSON"
„Wie sind aktuell die Benachrichtigungseinstellungen?"
Verfügbare Tool-Scopes
jobs:read
Jobs auflisten, Job-Details, Ausführungshistorie, Timeline-Statistiken, Tags.
jobs:write
Jobs erstellen, bearbeiten und löschen.
jobs:execute
Sofortigen Job-Start auslösen und laufende Ausführungen abbrechen.
export:read
Jobs als Crontab oder JSON exportieren.
maintenance:read/write
Wartungsfenster auflisten, erstellen, bearbeiten und löschen.
settings:read/write
Anwendungseinstellungen lesen und schreiben. Crontab neu synchronisieren.
- Details
- Geschrieben von: Cronmanager Admin
- Kategorie: CronManager DE
- Zugriffe: 84
Impressum
Angaben gemäß § 5 TMG
Verantwortlich
Christian Schulz
Medingstr. 3
29525 Uelzen
Kontakt
E-Mail:
Hinweis zur Website
Diese Website ist eine private, nicht-kommerzielle Projektseite für das Open-Source-Projekt CronManager, veröffentlicht unter der GPL-3.0-Lizenz. Über diese Website wird keinerlei kommerzielle Tätigkeit ausgeübt.
Haftungsausschluss
Haftung für Inhalte
Die Inhalte dieser Website wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als privater Diensteanbieter sind wir gemäß § 7 Abs. 1 TMG für eigene Inhalte auf diesen Seiten verantwortlich. Nach §§ 8–10 TMG sind wir jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.
Haftung für Links
Diese Website enthält Links zu externen Websites Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft; rechtswidrige Inhalte waren nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar.
Urheberrecht
Die durch den Seitenbetreiber erstellten Inhalte unterliegen dem deutschen Urheberrecht. Der Quellcode von CronManager ist unter der GPL-3.0-Lizenz auf GitHub veröffentlicht.
- Details
- Geschrieben von: Cronmanager Admin
- Kategorie: CronManager DE
- Zugriffe: 91
Cronjob läuft nicht? Häufige Ursachen und Lösungen
Wenn dein Cronjob nicht ausgeführt wird, bist du nicht allein. Dies ist eines der häufigsten Probleme auf Linux-Systemen. Die meisten Ursachen lassen sich in wenige Kategorien einteilen — und alle sind leicht zu debuggen, sobald man weiß, wo man suchen muss.
Häufige Ursachen
Falsche Cron-Syntax
Ein kleiner Fehler im Schedule-Ausdruck verhindert die Ausführung still und leise. Selbst ein fehlendes Leerzeichen oder eine falsche Feldanzahl stoppt den Job.
Fehlende Berechtigungen
Das Skript hat möglicherweise keine Ausführungsrechte, oder der Cron-User hat keinen Zugriff auf benötigte Dateien oder Verzeichnisse.
Umgebungsunterschiede
Cron läuft mit minimaler Umgebung — kein $PATH, keine Aliases, kein .bashrc. Befehle, die in der Shell funktionieren, schlagen in Cron oft still fehl.
Ausgabe nicht erfasst
Cron verwirft stdout und stderr standardmäßig. Ohne explizite Log-Umleitung sind Fehler vollständig unsichtbar.
Cron-Daemon läuft nicht
Auf manchen Systemen ist der Cron-Daemon gestoppt oder deaktiviert — alle Jobs werden dann still nicht ausgeführt.
Zeitzonenprobleme
Cron verwendet die System-Zeitzone. Läuft dein Server in UTC, werden Jobs möglicherweise zu unerwarteten lokalen Zeiten ausgeführt.
Wie du debuggen kannst
1. Prüfen ob der Cron-Daemon läuft
systemctl status cron # Debian/Ubuntu
systemctl status crond # RHEL/CentOS/Fedora2. Aktuelle Cron-Log-Einträge anzeigen
grep CRON /var/log/syslog | tail -30
# oder auf Systemen mit journald:
journalctl -u cron --since "1 hour ago"3. Crontab überprüfen
crontab -l # aktueller User
sudo crontab -l -u root # root-Crontab
ls /etc/cron.d/ # systemweite Einträge4. Skript-Berechtigungen prüfen
ls -la /pfad/zum/skript.sh
chmod +x /pfad/zum/skript.sh5. Mit Cron-Umgebung testen
env -i HOME=/root SHELL=/bin/bash \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
/bin/bash -c 'dein-befehl-hier'6. Ausgabe im Crontab-Eintrag erfassen
# stdout und stderr in eine Log-Datei schreiben:
* * * * * /pfad/zum/skript.sh >> /var/log/meinJob.log 2>&1Künftige Probleme verhindern mit Monitoring
Manuelles Debugging kostet Zeit. Ein Cron-Monitoring-Tool liefert Ausführungshistorie, Ausgabe-Logs und Fehlerbenachrichtigungen automatisch — sodass du sofort weißt, wenn etwas schiefläuft, ohne SSH-Zugriff.
Ausführungshistorie
Jeder Lauf mit Exit-Code, Dauer und vollständiger Ausgabe gespeichert. Kein manuelles Log-Durchsuchen mehr.
Sofortige Alerts
E-Mail-Benachrichtigung sobald ein Job fehlschlägt. Probleme erkennen, bevor sie Auswirkungen haben.
Multi-Server-Übersicht
Alle Cron-Jobs auf allen Servern in einem Dashboard. Kein SSH zum Statusprüfen erforderlich.
Cron-Jobs jetzt überwachen
CronManager ist kostenlos, quelloffen und selbst gehostet. Mit Docker in Minuten deployen.
Mit Docker installieren →- Details
- Geschrieben von: Cronmanager Admin
- Kategorie: CronManager DE
- Zugriffe: 94
Open-Source-Tools zur Cronjob-Überwachung
Wer ein Open-Source-Tool zur Cronjob-Überwachung sucht, findet nur wenige wirklich gute Optionen. Die meisten Lösungen sind SaaS-basiert mit laufenden Kosten, eingeschränkt im Funktionsumfang oder nicht mehr aktiv gepflegt.
Warum Open Source?
Volle Datenkontrolle
Ausführungslogs und Job-Konfigurationen bleiben auf deiner eigenen Infrastruktur. Keine Daten verlassen deine Server.
Keine laufenden Kosten
Kein Abonnement, keine Preisgestaltung pro Monitor, keine Nutzungslimits. Kostenlos unter GPL-3.0.
Flexibilität
Anpassen, erweitern und integrieren nach Bedarf. Vollständiger Quellcode-Zugriff auf GitHub.
Self-Hosted
Auf eigenen Servern deployen. Kein Vendor Lock-in, keine externen Abhängigkeiten, kein Account erforderlich.
CronManager vs SaaS-Alternativen
Cronitor, Healthchecks.io
Cloudbasierte Monitoring-Dienste. Nützlich für einfache Ping-basierte Prüfungen, erfordern aber das Senden von Daten an externe Server, berechnen pro Monitor ab einer bestimmten Anzahl und begrenzen die Log-Tiefe in kostenlosen Tarifen.
CronManager
Self-hosted, quelloffen, aktiv gepflegt. Vollständige Ausgabeerfassung, Multi-Server-Monitoring, Fehlerbenachrichtigungen, Laufzeitlimits und OIDC/SSO — ohne Abonnement.
CronManager Highlights
Ausführungshistorie & Logs
Vollständige stdout/stderr-Erfassung für jeden Lauf. Timeline-Diagramme, Swimlane-Ansichten und KPI-Karten pro Job.
Fehlerbenachrichtigungen
E-Mail-Benachrichtigungen bei Fehler-Exit-Codes. Pro Job konfigurierbar.
Multi-Host-Monitoring
Cron-Jobs auf mehreren Linux-Servern von einem Dashboard überwachen. SSH-basierte Remote-Ausführung inklusive.
OIDC / SSO
Integration mit Authentik, Keycloak oder jedem standardkonformen Identity Provider.
Kostenlos starten
Self-hosted, quelloffen, GPL-3.0. Kein Account erforderlich.
Mit Docker installieren →- Details
- Geschrieben von: Cronmanager Admin
- Kategorie: CronManager DE
- Zugriffe: 94
CronManager installieren — Agent auf dem Host
Diese Methode eignet sich, wenn der CronManager-Agent direkt auf dem Host laufen soll statt in einem Docker-Container. Die Web-UI läuft weiterhin als Docker-Container. Das Setup-Skript installiert und konfiguriert alles automatisch.
Ein-Befehl-Setup
curl -fsSL https://raw.githubusercontent.com/csoscd/cronmanager/main/simple_debian_setup.sh | bashDas Skript installiert PHP, richtet den Agent als systemd-Dienst ein und startet den Web-Container.
Wann diese Methode wählen?
Direkter Host-Zugriff
Der Agent läuft als systemd-Dienst direkt auf dem Host-OS und hat direkten Zugriff auf die Cron-Umgebung und lokale Prozesse.
Geringerer Overhead
Kein Container für den Agent — geeignet für ressourcenbeschränkte Umgebungen oder spezifische Sicherheitsanforderungen.
Eigenes PHP-Setup
Sinnvoll, wenn PHP bereits auf dem Host verwaltet wird und der Agent in dieser Umgebung laufen soll.
Voraussetzungen
Anforderungen
Debian oder Ubuntu Linux. Docker und Docker Compose v2. PHP 8.x auf dem Host.
Vollständig containerisiertes Setup bevorzugt? Zur Docker-Compose-Installation →