Typische Stolperfallen: Warum Cronjobs auf Shared Hosting oft schiefgehen
Klingt simpel: Automatischer Newsletter, tägliches Backup, ein paar PHP-Skripte per Cron. Die Realität sieht meistens anders aus. Shared Hosting hat Regeln, die keiner vorher liest. Wer Cronjobs im Minutentakt startet, bekommt oft schneller Post vom Rate-Limit als Erfolgsmeldungen vom Script. Ganz vorne dabei: Jobs, die kommentarlos abbrechen oder einfach verschwinden. Manchmal wird sogar der Cron für den ganzen Account gesperrt. Die Ursache? Nicht nur die Cronjob-Konfiguration. Oft stimmen PHP-Pfade nicht, die falsche CLI-Version läuft oder Fehlermeldungen gehen ins Nirwana. Typisch.
PHP-CLI-Version: Welcher Interpreter läuft eigentlich?
Klassiker: Das Web läuft auf PHP 8.2, aber der Cronjob nutzt noch PHP 7.4 – oder schlimmer. Viele Hoster haben unter /usr/bin/php eine alte PHP-CLI liegen. Das Projekt will aber Features aus 8.1 oder 8.2. Ergebnis: Fehlermeldungen, weil Extensions fehlen oder Syntax nicht passt.
Gerne übersehen: Im Cronjob steht einfach „php /home/user/web/cron/script.php“. Das reicht selten. Entweder ist php gar nicht verlinkt, oder es zeigt auf die falsche Version. Besser: Den vollen Pfad zur passenden CLI-Version nehmen. Beispiel aus der Praxis:
Code:
/opt/php-8.2/bin/php /home/user/web/cron/script.phpWelcher Pfad gültig ist, steht meist irgendwo in der FAQ oder kommt vom Hoster-Support (wenn man hartnäckig fragt). Ohne den richtigen PHP-Interpreter kann man sich das Debugging sparen. In Agenturen taucht dieser Fehler bei fast jedem dritten Shared-Hosting-Projekt auf.
Logging: Keine Logs, keine Kontrolle
Cronjobs laufen leise. Sehr leise. Wer keine Logs schreibt, merkt von Fehlern oft gar nichts – bis die Kunden meckern oder Daten fehlen. Empfehlung: Ausgabe und Fehler gleich in eine Logdatei umleiten.
Code:
/opt/php-8.2/bin/php /home/user/web/cron/script.php >> /home/user/logs/cron_script.log 2>&1So landen alle Meldungen in einer Datei. Hilft beim Nachvollziehen, was passiert – oder eben nicht passiert. Aber Vorsicht: Die Logdatei wächst schnell. Einmal übersehen, und plötzlich platzt das Quota. Also: Log regelmäßig leeren oder per Logrotate automatisch drehen lassen. Spart Nerven.
Was immer wieder schiefgeht (und wie es besser läuft)
- PHP-Pfad falsch: Cronjob läuft nicht oder nimmt die falsche Version.
- Rechtechaos: Script nicht lesbar oder nicht ausführbar für den Cron-Benutzer.
- Timeout zu eng: Viele Hoster kappen nach 30 Sekunden – längere Aufgaben lieber splitten oder ganz lassen.
- Umgebungsvariablen fehlen: Pfade und Zugangsdaten im Script hart eintragen, sonst sucht man ewig.
- Kein Logging: Fehler rauschen durch, bis es zu spät ist.
Testen ohne Limit-Ärger: Erst gucken, dann einbauen
Shared Hosting ist empfindlich, was Cronjobs angeht. Ein Ausrutscher, und der Account hängt in der Warteschleife. Vorgehen, das sich bewährt hat:
- Erst per SSH den Job manuell starten. Gibt’s Fehlermeldungen? Wie lang läuft das Ding?
- Zeitintervalle großzügig wählen. Jede Minute ist selten nötig. 5 bis 10 Minuten reichen meistens.
- Größere Aufgaben aufteilen, nicht alles in einen Rutsch quetschen.
- Im Log Zeitstempel schreiben, dann sieht man Dauer und Auslastung.
Wer die Wahl hat, legt Cronjobs außerhalb der Hauptzeiten. Dann bricht nichts zusammen, wenn alle im Shop stöbern. Bringt Ruhe rein.
Alternative: Externer Cron-Service ruft das PHP-Skript per URL auf
Nicht jeder Job muss über den Hoster-Cron laufen. Es gibt externe Dienste, die in festen Intervallen eine URL aufrufen – und damit ein PHP-Skript über den normalen Webserver starten. Bekannte Beispiele: cron-job.org, EasyCron oder ähnliche „Webhook-/URL-Cron“-Anbieter. Manche nutzen auch Monitoring-Tools (z. B. Uptime-Checks), um alle X Minuten eine geschützte Endpoint-URL anzupingen.
Der Vorteil: Es läuft dieselbe PHP-Version wie die Website – kein CLI-Pfad-Rätsel. Und man umgeht oft die strengen Hoster-Cron-Limits, weil der Request von außen kommt wie ein normaler Seitenaufruf.
So sieht der Alltag aus:
- Skript unter einer URL erreichbar machen, z. B.
https://beispiel.de/cron/backup.php?key=GEHEIMER_TOKEN- Beim Anbieter Intervall und URL hinterlegen
- Im Skript den Token prüfen – ohne Token kein Job. Optional: nur bestimmte User-Agents oder IP-Ranges zulassen
- Antwort kurz und klar halten (HTTP 200 + „OK“), damit der Dienst den Lauf als erfolgreich wertet
- Lange Jobs splitten: Web-PHP hat oft dieselben Timeouts wie der Browser-Request (30–60 Sekunden)
Was man nicht vergessen sollte: Die URL ist öffentlich erreichbar, wenn man nicht absichert. Ohne Token oder Signatur läuft irgendwann jeder den Job – oder schlimmer, startet teure Operationen. Und wer den externen Dienst abschaltet oder das Abo ausläuft, stehen die Automatisierungen still. Für viele kleine Shared-Hosting-Projekte ist das trotzdem der pragmatischere Weg als der kaputte Panel-Cron.
Meine Einschätzung nach 30 Jahren Webentwicklung
Shared Hosting und Cronjobs – das bleibt eine Zweckgemeinschaft. Für einfache Tasks passt das meist, solange die Limits eingehalten werden. Klemmt der Panel-Cron oder ist er zu streng limitiert, ist ein externer URL-Aufruf oft die bessere Notlösung als stundenlanges Debugging am Hoster-Cron. Bei allem, was auf die Sekunde genau laufen oder mehr als ein bisschen Last machen soll: lieber direkt einen VPS oder Managed Server nehmen. Inzwischen sind die Hoster viel strenger geworden. Wird ein Account zu forsch, gibt’s schnell eine Sperre oder eine freundliche Mail vom Support.
In der Praxis heißt das:
- PHP-CLI-Pfad immer fest eintragen, nie auf „php“ allein verlassen
- Absolute Pfade, keine ../-Konstrukte
- Logging einbauen, regelmäßig prüfen – und die Logs nicht ausarten lassen
- Intervalle großzügig, Jobs lieber nachts oder außerhalb der Rushhour laufen lassen
- Wer für mehrere Kunden Shared Hosting betreut: Support-Tickets landen öfter auf dem Tisch, wenn Cronjobs nicht sauber laufen
- Einzelentwickler mit kleinen Scripten oder WordPress-Plugins fahren besser, wenn sie Intervall und Logging konservativ halten und ab und zu händisch testen
Mehr Kontrolle und Flexibilität gibt’s nur mit eigenem Server. Alles andere ist ein Kompromiss – manchmal reicht’s, manchmal nicht. Kommt auf die Nervenstärke an.
Weiterlesen: Praxistipps und Sicherheit
Wer noch tiefer einsteigen will: Im JSWelt-Forum gibt’s einen Thread mit Beispielen und typischen Fehlern — Cronjobs auf Shared Hosting: Wo es klemmt – und wie sie dann doch laufen.
Für alle mit Altprojekten: Hier gibt’s Hinweise zu typischen Sicherheitsrisiken, die auch bei automatisierten Jobs nerven können: PHP-Altprojekte absichern: OWASP-Check für SQL-Injection, XSS und Session-Fixation.
Fazit
Cronjobs auf Shared Hosting laufen – wenn PHP-Pfad, Logging und Intervalle stimmen. Klemmt der Hoster-Cron, reicht oft ein externer Dienst, der das PHP-Skript per URL anstößt. Wer Limits, Absicherung und Timeouts im Blick behält, kommt meist ohne Ärger durch. Für größere Automatisierung: besser direkt einen Server nehmen.
bye
mo