Manage scheduled jobs

Open an App and select Scheduled Jobs.

Only Team owners and admins can change scheduled-job definitions.

The Jobs tab shows the scheduler-wide control and each saved job’s latest result and next run; the History tab holds the run-history table.

Turn scheduled jobs on or off

The Scheduled jobs enabled control pauses or resumes the scheduler for the App. Disabling it preserves every job definition.

Use the per-job Active control when you want to pause only one job. Pause a job instead of deleting it when you expect to use the same definition again.

Change scheduled jobs through MCP

A Control connection with config.read and config.write edits the same settings through configure_services:

1. Call get_site_configuration and retain its revision_token.
2. Call configure_services with a jobs object: enabled sets the scheduler control, timeZone sets the zone the schedules run in (a name such as Europe/Berlin, or an empty string for UTC), and cron replaces the full job list. Each job carries name, schedule, command, and optionally concurrencyPolicy and enabled. concurrencyPolicy is Forbid (the default: a run is skipped while the prior run is still active) or Allow (runs overlap).
3. Include the revision token, an idempotency key, and confirmation.
4. Follow the returned deployment ID with deploy_status.

Send every job you want to keep in cron; a job left out of the list is removed. Send only enabled to pause or resume the scheduler without changing the job list. In the App’s config file, a jobs block without timeZone runs its schedules in UTC.

Add or edit a job

1. Turn scheduled jobs on if the App doesn’t already use them.
2. Select Add job.
3. Enter a unique name and the command to run.
4. Build a schedule with the schedule controls, or use the advanced cron field.
5. Choose how overlapping runs are handled.
6. Leave Active on unless the job should be created in a paused state.
7. Save and confirm the apply.

An App can have up to 50 scheduled jobs.

Write a schedule

Advanced schedules use the standard five-field format:

minute hour day-of-month month day-of-week

For example, 0 2 * * * runs daily at 2:00 AM. The portal also accepts the nicknames @hourly, @daily, @weekly, @monthly, @yearly, and @annually, written in lowercase.

The scheduler doesn’t run @midnight, @every, @reboot, or a nickname in another case such as @Daily, so the portal rejects them. Use @daily or 0 0 * * * for a run at midnight.

Month and day names such as JAN or Mon work in any case. A step can’t exceed its field’s maximum, so */60 is rejected in the minute field. A range must run forward once names become numbers, and Sunday counts as 0, so sat-sun and 1-7 are rejected. Use a list such as sat,sun, or * for every day.

Invalid schedules are rejected before the change is saved.

Choose a time zone for schedules

Schedules run in UTC unless you choose a zone. Under Time zone for schedules, pick the zone the App’s schedules should follow, such as your store’s zone. One zone applies to every job of the App, and the scheduler follows that zone’s daylight-saving changes, so 0 2 * * * in Europe/Berlin runs at 2:00 AM Berlin time all year (00:00 UTC in summer, 01:00 UTC in winter).

The page shows each job’s next run and every run time in History in that zone, with the zone’s name, so everyone on your team reads the same times. A zone name that isn’t in the time zone database is rejected before the change is saved. Choose UTC (default) to go back to UTC.

Magento’s own cron follows the store’s time zone inside magento-cron, which runs every minute, so this setting doesn’t change when Magento’s jobs run.

When a saved schedule can’t run

The scheduler checks each job’s schedule every time it starts. It leaves out a job whose schedule it rejects: the job shows Invalid schedule on the Jobs tab with no next run, and its History row names the job and the schedule. Your other jobs keep running, and the saved definition doesn’t change.

A schedule saved before the portal began rejecting it can reach this state. Edit the job’s schedule to a supported form and save it to resume the job. The job then shows Waiting for next run until it runs, and History keeps the rejected record.

Control overlapping runs

• Under If a run is still going, choose Wait for it to finish to prevent a new run from starting while the prior run is still active.
• Choose Run anyway (overlap) when overlapping runs are safe.

Use Wait for it to finish unless the command is safe to execute concurrently.

A job set to Wait for it to finish that is still running when its next run comes due gets a Skipped row in History for that run. A job set to Run anyway (overlap) runs at most two copies at once; a third is skipped.

The scheduler runs up to two of your jobs at the same time, whatever their names. A job that comes due while two are already running is skipped for that run, and its History row names the jobs that were running. Your App’s own scheduler (magento-cron or shopware-cron, and its cron-group and catch-up runs) isn’t counted and never waits for your jobs, so long exports or imports can’t stop Magento’s or Shopware’s own scheduled work. Spread long jobs across the day, or combine them into one job, when more than two can be due at once.

Apply scheduler changes

Saving a changed job definition restarts the scheduled-job runner. The serving App remains online, but scheduled execution pauses during the apply. The editor remains locked until the operation reaches a final result.

When a restart meets a running job

A deploy, an Apply now, a scheduler change, or a service change that restarts the App’s runners never cuts off a job mid-run. The scheduler stops starting new runs and gives each running job up to 30 minutes to finish. A job still running after 30 minutes is stopped and its run shows Terminated, so history always records how it ended.

While the scheduler waits, the apply status reads Waiting for a running scheduled job. On a Magento App a deploy also waits up to 30 minutes for a running index rebuild to finish before it replaces the pods running it. If the rebuild is still running then, the deploy fails, naming the indexer, and the current release keeps serving.

A run that was due while the scheduler was stopped is skipped, not run late. If a job must run after every restart, give it a frequent schedule.

The apply completes only after the restarted scheduler is running with the new job list. If the scheduler doesn’t start, the apply fails. On a suspended App, the apply completes without starting the scheduler, and the scheduler starts when the App resumes.

Follow the apply status and then verify the next expected run. A successful apply proves that the scheduler restarted with the new job list; it doesn’t prove that each command succeeds. A job whose schedule the scheduler rejected still shows Invalid schedule.

Review run history

Each job row shows its latest outcome. An active job also shows its next run time after the scheduler has calculated one.

Open the History tab to review:

• completed, failed, timed-out, terminated, and skipped runs, plus Invalid schedule records;
• start time, in the App’s schedule time zone, and duration;
• why each skipped run was skipped;
• captured customer-safe output;
• the most recent 30 days, 90 days, or one year;
• one job or all jobs;
• newest or oldest results, with paginated results.

History keeps the first 16 KiB and the last 16 KiB of each run’s output, with a line saying how many bytes were cut between them, so both an early error and the final result stay visible. A run’s full output, up to 8 MiB, is also in Diagnostics → Logs: filter by the cron container and the run’s time, and search for the job’s name, which starts each output line as [job-name]. Run history is retained for one year; Logs keeps output for 30 days.

For framework command examples and duplicate-scheduler precautions, see Operate WordPress or Operate Magento.

Understand job status

• Succeeded means the command exited successfully.
• Failed (exit N) means it returned a nonzero exit code.
• Timed out means it exceeded its allowed runtime.
• Terminated means a restart stopped it after its 30 minutes to finish. See When a restart meets a running job.
• Skipped means the run didn’t start: the job’s previous run was still going, the job already had two overlapping runs, or two of your jobs were already running. The card and the History row say which.
• Waiting for first run means the schedule hasn’t executed yet.
• Invalid schedule means the scheduler left the job out at its last start. See When a saved schedule can’t run.
• Waiting for next run means you corrected a rejected schedule and the job hasn’t run since.
• Not running means the scheduler itself is down, so no job runs.
• Status unavailable means the portal couldn’t load current scheduler telemetry; it doesn’t change the saved definition.

Paused jobs and globally disabled scheduling don’t show a next run time.

A job’s result comes from its run history, so an older Succeeded doesn’t prove the scheduler is running now. The page checks the scheduler separately. When the scheduler is down, the Jobs tab says that none of your jobs are running, every job shows Not running, and no next run appears. When synsmarts can’t measure the scheduler, the page shows each job’s latest result without that message, so a missing message doesn’t prove the scheduler is running.

If the scheduler is down or keeps restarting, an alert also appears in Diagnostics within five minutes. A suspended App shows neither the message nor the alert.

The job that runs your App’s scheduler has its own alert: the job your App was created with, or on a migrated Magento store the one job whose command runs bin/magento cron:run. The alert appears in Diagnostics when that job hasn’t completed a run successfully for more than 10 minutes. For magento-cron and shopware-cron, that covers a paused or deleted job, runs that keep failing, and one run that’s still holding the job. On Magento, the history also lists magento-cron’s cron-group runs, such as magento-cron.index, and its catch-up runs, magento-cron.catchup; they don’t raise this alert. For wp-cron, it covers only runs that keep failing, because pausing wp-cron is how you return to traffic-driven WordPress cron. A suspended App doesn’t raise it.

Recover from a problem

• Correct inline schedule, name, command, or concurrency errors before saving.
• If a job shows Invalid schedule, correct its schedule and save.
• If your jobs show Not running, review the alert in Diagnostics and get support when it doesn’t clear.
• If the revision is stale, select Load the latest and repeat the edit.
• If another App operation is active, wait for it to finish.
• If an apply fails or its status is unknown, select Load the latest before retrying.
• If run history can’t be loaded, retry the history request. The saved schedule continues to operate independently of the history view.