📖 Dokumentation

Willkommen beim CronJob Server – deinem eigenen Online-Web-Cron-Service. Diese Anleitung erklärt Installation, Einrichtung und Bedienung.

Installation

Der Cron-Job-Server wird über den Installer cron_install.php + files.zip eingerichtet:

1. cron_install.php und files.zip in das Zielverzeichnis deines VPS hochladen (z.B. /var/www/cron).
2. Im Browser aufrufen: https://deine-domain.de/cron_install.php
3. Den 6-Schritte-Wizard durchlaufen:
   • System – Prüfung der PHP-Erweiterungen (Zip, PDO-MySQL, cURL, mbstring, OpenSSL)
   • Datenbank – MySQL-Zugangsdaten (Datenbank muss existieren)
   • App – Name, URL, Absender-E-Mail, Zeitzone
   • Admin – Administrator-Zugang
   • Installieren – Tabellen anlegen, Dateien entpacken, .env schreiben
   • Fertig – Scheduler-Einrichtung + Dateien löschen
4. Nach der Installation cron_install.php und files.zip löschen (der Wizard bietet das an).

Voraussetzungen

• PHP ≥ 8.1 mit den Erweiterungen pdo_mysql, mbstring, openssl, curl, zip (zip nur für den Installer)
• MySQL / MariaDB
• Schreibrechte für das App-Verzeichnis und logs/

Scheduler einrichten

Damit fällige Jobs ausgeführt werden, muss der Runner regelmäßig laufen. Es gibt zwei Wege – empfohlen ist die Crontab auf dem VPS:

Variante 1: Crontab (empfohlen)

Eine Zeile in der Crontab deines Systems (z.B. crontab -e):

* * * * * php /pfad/zu/runner.php >> /pfad/zu/logs/runner.log 2>&1

So läuft der Scheduler einmal pro Minute. Der Runner nutzt eine Lock-Datei (logs/scheduler.lock), damit parallele Läufe niemals denselben Job doppelt ausführen.

Variante 2: Web-Cron

Falls du keine Crontab anlegen kannst (z.B. beim Webhosting), rufst du den Runner per HTTP auf – zum Beispiel mit einem externen Web-Cron-Dienst, der die URL einmal pro Minute abruft:

curl "https://deine-domain.de/runner.php?key=DEIN_RUNNER_KEY"

Den RUNNER_KEY findest du nach der Installation in der .env (oder im Admin-Bereich). Die URL ist ohne den korrekten Key nicht aufrufbar.

Daemon-Modus

Alternativ kann der Runner als Endlosschleife laufen (z.B. per systemd):

php /pfad/zu/runner.php --daemon

Er prüft dann alle 10 Sekunden auf fällige Jobs. Einzelne Läufe außerhalb des Daemons sind weiterhin möglich.

Cron-Jobs anlegen

1. Im Dashboard auf „+ Neuer Job“ klicken.
2. Titel und Ziel-URL angeben (nur http:// oder https://).
3. Methode wählen: GET, POST, PUT, PATCH oder DELETE. Bei Bedarf Body, Content-Type und eigene Header setzen.
4. Zeitplan wählen: Fertige Intervalle oder eigene Cron-Expression. Eine Live-Vorschau zeigt die nächsten 5 Ausführungen.
5. Timeout und Fehler-Benachrichtigung einstellen.
6. Speichern – fertig. Der Scheduler übernimmt die Ausführung automatisch.

Cron-Expression

Eine Cron-Expression besteht aus 5 Feldern, durch Leerzeichen getrennt:

Minute   Stunde   Tag      Monat    Wochentag
0-59     0-23     1-31     1-12     0-7 (0=So, 7=So)

Monatsnamen (jan–dec) und Wochentagsnamen (sun–sat) werden ebenfalls akzeptiert, z.B. 0 9 * * mon-fri.

Hinweis: Sind Tag UND Wochentag beide eingeschränkt, gilt ODER-Verknüpfung (wie in der Standard-Crontab).

HTTP-Ausführung

Die Ausführung erfolgt mit cURL, falls verfügbar, sonst mit einem Stream-Fallback. Erfasst werden:

• HTTP-Statuscode
• Antwortzeit in Millisekunden
• Antwortgröße in Bytes
• Die ersten Zeichen der Antwort (Vorschau, konfigurierbar)
• Fehlermeldungen (Timeout, Verbindungsfehler, DNS …)

Weiterleitungen werden standardmäßig verfolgt (max. 5 Sprünge), die SSL-Zertifikate werden geprüft.

Benachrichtigungen

Ist „E-Mail bei Fehlschlag“ aktiviert, erhältst du bei jedem endgültig fehlgeschlagenen Lauf eine E-Mail – gedrosselt auf maximal eine pro Stunde pro Job (Intervall im Admin-Bereich einstellbar), damit der Server bei anhaltenden Problemen nicht zuspammt.

Als Empfänger gilt: die pro Job hinterlegte E-Mail, sonst deine registrierte E-Mail.

Retries & Aufräumen

Pro Job lässt sich eine automatische Wiederholung einstellen: Schlägt ein Lauf fehl (Netzwerkfehler, Timeout oder HTTP 5xx), führt der Scheduler den Job nach dem eingestellten Intervall erneut aus – bis zur maximalen Anzahl an Wiederholungen. Jeder Versuch wird im Laufprotokoll festgehalten (Spalte „Versuch“). Benachrichtigungen werden erst nach dem letzten Versuch verschickt.

Der Scheduler räumt außerdem automatisch auf (einmal täglich): alte Laufprotokolle werden nach der eingestellten Aufbewahrungsdauer (cleanup_runs_days, Standard 90 Tage) gelöscht, ebenso abgelaufene Verifikations-/Passwort-Token und alte API-Zähler.

REST-API

Deine Jobs lassen sich auch per API verwalten. Erstelle dazu unter api_keys.php einen API-Schlüssel und sende ihn als Bearer-Token mit. Der Schlüssel wird nur einmal angezeigt.

Basis-URL: api.php (ohne Rewrite) bzw. /api (mit Rewrite).

Beispiel (Job anlegen):

curl -s -X POST -H "Authorization: Bearer DEIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"Backup","url":"https://beispiel.de/cron.php","schedule":"0 3 * * *","retry_count":2}' \
  "https://deine-domain.de/api.php?route=jobs"

Fehler werden als {"ok":false,"error":"..."} mit passendem HTTP-Statuscode beantwortet. Jeder Schlüssel ist auf eine konfigurierbare Anzahl Anfragen pro Minute begrenzt (Standard 60).

Admin-Bereich

Der Admin-Bereich (admin.php) wird mit dem im Installer angelegten Admin-Konto betreten und bietet:

• System – Status des Schedulers, Umgebungsprüfung, Statistik
• Benutzer – Konten freischalten, sperren, löschen, Rollen vergeben
• Einstellungen – Registrierung (+ Schutz), Limits, Retries, Aufräumen, REST-API, SSRF-Schutz, Runner-Key, Mail/SMTP, Branding, Rechtstexte
• Alle Läufe – Laufprotokoll über alle Benutzer

Sicherheit

• SSRF-Schutz – Private/lokale IP-Ranges (10/8, 172.16/12, 192.168/16, loopback, ULA, …) werden als Ziel blockiert. Nur http(s) ist erlaubt. Abschaltbar in den Einstellungen (für eigene Netzwerke).
• Alle Passwörter werden als bcrypt-Hash gespeichert.
• CSRF-Schutz auf allen Formularen, Session-Regeneration bei Login.
• Brute-Force-Schutz für Benutzer- und Admin-Login (Kontosperre, IP-Limit).
• Registrierungs-Schutz – Rechen-Captcha, Honeypot-Felder, Mindest-Formularzeit und IP-/E-Mail-Rate-Limits gegen Spam-Registrierungen.
• API-Schlüssel werden nur als SHA-256-Hash gespeichert und per Schlüssel auf Anfragen pro Minute begrenzt.
• .env und interne Dateien sind per .htaccess gesperrt.
• Der Web-Cron-Endpunkt runner.php ist nur mit gültigem RUNNER_KEY aufrufbar.

FAQ

Mein Job läuft nicht. Woran kann das liegen?

• Prüfe unter Admin → System, ob der Scheduler überhaupt läuft (letzter Lauf nicht älter als 2 Minuten).
• Ist der Job pausiert?
• Kann dein Server die Ziel-URL erreichen? Fehlermeldungen stehen im Laufprotokoll.
• Wird die Ziel-URL durch den SSRF-Schutz blockiert (private IP)?

Wie präzise ist die Ausführung?

Der Scheduler läuft einmal pro Minute (Crontab) und führt alle fälligen Jobs aus. Die Zeitplanung ist minutengenau; die tatsächliche Sekunde hängt davon ab, wann der Runner-Lauf den Job erreicht.

Kann ich auch lokale Kommandos ausführen?

Nein. Der Cron-Job-Server ruft ausschließlich HTTP(S)-URLs auf (Web-Cron, wie bei cronjob.de). Das hält das Sicherheitsmodell einfach und risikoarm.

Was passiert bei einem Timeout?

Der Lauf wird abgebrochen und als timeout geloggt. Sind Retries konfiguriert, folgen automatische Wiederholungen; danach wird – falls aktiviert – eine Fehler-Mail versendet. Der nächste geplante Lauf findet wie gewohnt statt.