Behoben. Seit über einer Stunde laufen alle Cronjobs fehlerfrei. Neu ist die Art „Befehl“: Damit laufen Cron-Skripte wie bei klassischem Hosting direkt im Container (z. B. php cron/aufgabe.php), ohne Token im Aufruf. Exit-Code und Ausgabe siehst du unter Cronjobs → Verlauf.

Seit der letzten Korrektur um 20:14 Uhr sind alle Cronjobs fehlerfrei gelaufen, HTTP-Aufrufe genauso wie Befehle. Wir beobachten noch bis etwa 21:15 Uhr und schließen den Vorfall dann.

Nachbesserung: Wenn ein Befehls-Cronjob genau während eines neuen Deploys startete, konnte er abgelehnt werden. Das ist behoben, Befehle laufen jetzt immer mit dem Stand der Instanz, neben der sie starten. Seitdem laufen alle Cronjobs fehlerfrei. Wir beobachten noch eine Weile.

Neu: Befehls-Cronjobs. Unter Cronjobs → Neuer Cronjob wählst du bei „Art“ jetzt „Befehl“ und trägst z. B. php cron/aufgabe.php ein. Der Befehl läuft in einer Kopie deines Containers, mit denselben Umgebungsvariablen, Dateien und demselben Speicher, ganz ohne Token. Exit-Code und Ausgabe stehen im Verlauf.

Bei den betroffenen Cronjobs ist der Token jetzt im Aufruf, und sie laufen wieder erfolgreich. Wir beobachten die nächsten Läufe.

Als Nächstes bauen wir Befehls-Cronjobs: Deploy kann dann neben einem HTTP-Aufruf auch einen Befehl wie php cron/aufgabe.php ausführen, so wie du es von klassischem Hosting kennst.

Ursache gefunden: Die Cronjobs von Deploy laufen pünktlich und erreichen die Apps. Die betroffenen Aufrufe hat die jeweilige App selbst mit „403 Forbidden“ abgelehnt, weil ihr ein Zugangs-Token im Aufruf fehlte.

Wenn dein Cron-Skript einen Token erwartet, häng ihn an den Pfad an, z. B. /cron/aufgabe.php?token=…. Den Wert siehst du in deiner App. Im Dashboard wird er danach als •••• angezeigt. Das Ergebnis jedes Laufs findest du unter Cronjobs → Verlauf.

Bei CitexNode Deploy schlagen gerade viele Cronjobs fehl oder laufen nicht an. Deine Websites selbst sind erreichbar, betroffen sind nur die zeitgesteuerten Aufrufe. Wir sehen uns das an.