Resolved. All cron jobs have run without errors for over an hour. New is the "Command" type: cron scripts run directly in the container as on classic hosting (e.g. php cron/task.php), with no token in the call. Exit code and output are shown under Cron jobs → History.

Since the last fix at 20:14 all cron jobs have run without errors, HTTP calls and commands alike. We are watching until about 21:15 and will then close the incident.

Follow-up fix: a command cron job that started exactly during a new deploy could be rejected. That is fixed; commands now always run with the version of the instance they start next to. Since then all cron jobs have run without errors. We are watching for a while longer.

New: command cron jobs. Under Cron jobs → New cron job, choose "Command" as the type and enter e.g. php cron/task.php. The command runs in a copy of your container with the same environment variables, files and storage – no token needed. Exit code and output are shown in the history.

The affected cron jobs now include the token in their call and are running successfully again. We are watching the next runs.

Next we are building command cron jobs: besides an HTTP call, Deploy will then be able to run a command such as php cron/task.php, as you know it from classic hosting.

Cause found: Deploy's cron jobs run on time and reach the apps. The affected calls were rejected by the app itself with "403 Forbidden" because an access token was missing from the call.

If your cron script expects a token, add it to the path, e.g. /cron/task.php?token=…. You find the value in your app; the dashboard then shows it as ••••. The result of every run is under Cron jobs → History.

On CitexNode Deploy many cron jobs are currently failing or not starting. Your websites themselves are reachable; only the scheduled calls are affected. We are looking into it.