📖 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:

cron_install.php und files.zip in das Zielverzeichnis deines VPS hochladen (z.B. /var/www/cron).
Im Browser aufrufen: https://deine-domain.de/cron_install.php
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
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. Der Scheduler startet dabei automatisch im Hintergrund, sobald eine Seite aufgerufen wird und Jobs fällig sind (Fallback, max. alle 30 Sekunden). Für zuverlässige Ausführung ohne Besucher zusätzlich einen echten Cron einrichten – 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.

Kontrolle: Unter Admin → System siehst du den Zeitpunkt des letzten Scheduler-Laufs. Bleibt er stehen und es gibt keine Seitenaufrufe mehr, läuft dein Cronjob nicht (mehr).

Cron-Jobs anlegen

Im Dashboard auf „+ Neuer Job“ klicken.
Titel und Ziel-URL angeben (nur http:// oder https://).
Methode wählen: GET, POST, PUT, PATCH oder DELETE. Bei Bedarf Body, Content-Type und eigene Header setzen.
Zeitplan wählen: Fertige Intervalle oder eigene Cron-Expression. Eine Live-Vorschau zeigt die nächsten 5 Ausführungen.
Timeout und Fehler-Benachrichtigung einstellen.
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)

Zeichen	Bedeutung	Beispiel
`*`	Jeder Wert	`*` in Minute = jede Minute
`*/n`	Jeder n-te Wert	`/5 * * *` = alle 5 Minuten
`a-b`	Bereich	`0 9-17 * * *` = stündlich zwischen 09 und 17 Uhr
`a,b,c`	Liste	`0 0 * * 1,3,5` = Mo, Mi, Fr um 00:00

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.

Im Dashboard (Admin) und unter Admin → System siehst du, wann zuletzt bereinigt wurde und wie viele Laufprotokolle dabei gelöscht wurden. Unter Admin → Einstellungen → Werkzeuge kannst du mit „Manuell aufräumen“ das Löschen zusätzlich sofort anstoßen.

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. Auf manchen Servern (z. B. FastCGI) wird der Authorization-Header vom Provider nicht durchgereicht – dann den Key alternativ als X-API-Key: DEIN_KEY-Header senden.

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

Methode & Pfad	Beschreibung
GET /api.php?route=me	Eigenes Konto + Key-Name
GET /api.php?route=jobs	Alle eigenen Jobs
POST /api.php?route=jobs	Job anlegen (JSON-Body)
GET /api.php?route=jobs/{id}	Einzelnen Job abrufen
PUT /api.php?route=jobs/{id}	Job aktualisieren
DELETE /api.php?route=jobs/{id}	Job löschen
POST /api.php?route=jobs/{id}/run	Job sofort ausführen
GET /api.php?route=jobs/{id}/runs	Laufhistorie (Parameter `limit`)
GET /api.php?route=status	Server-Status

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 anlegen, bearbeiten (inkl. Passwort, Rolle, Status), freischalten, sperren und löschen
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).
Der automatische Start reagiert nur auf Seitenaufrufe – bei selten besuchten Seiten zusätzlich einen echten Cron einrichten (siehe oben).
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. Ohne echten Cron startet er beim nächsten Seitenaufruf (max. 30 Sekunden später).

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.