n8n 2.32.6 - Five Field Cron Schedule Fix

n8n published [email protected] on July 29, 2026. This patch restores acceptance of five field cron expressions in the Schedule Trigger, a narrow core fix with direct consequences for workflow scheduling compatibility.

The full release notes and downloads are on the GitHub release page.

The release contains one listed code change. The core Schedule Trigger now accepts cron expressions with five fields. The correction is tracked in issue 35013 and implemented by commit 0de32f0.

A five field expression represents minute, hour, day of month, month, and day of week. For example, */5 * * * * describes a schedule at five minute intervals. The release notes describe acceptance of this input shape. They do not claim a change to cron evaluation, task execution, retry behavior, or workflow persistence.

That boundary matters. This is a compatibility correction in the schedule configuration path, not a scheduler redesign. Operators should expect a previously rejected five field expression to pass the relevant validation after the upgrade. They should not infer broader timing or execution fixes from this patch.

Scheduled workflows often sit at the start of ingestion, synchronization, and reporting pipelines. A rejected cron expression can stop that work before execution begins, even when the expression already matches the common five field form used by other schedulers. Restoring acceptance reduces format friction when schedules move into n8n from templates or configuration repositories.

The release notes list no connector changes, database migration, queue behavior update, or schema change. They also list no breaking change. That keeps the upgrade surface small, but it limits what this release can reasonably be expected to fix. Pipeline failures after a schedule has been accepted still require separate investigation.

If an existing deployment carries a workaround for rejected five field schedules, do not remove it blindly. First confirm how the affected workflow is created, saved, activated, and executed in the target environment. The release fixes acceptance, while local policy checks or external workflow generators may still impose their own format rules.

The most useful regression test is a small scheduled workflow in a nonproduction environment. Configure a Schedule Trigger with a representative five field expression, save and activate the workflow, then observe at least two expected runs. Use the same creation path as production, such as an imported workflow definition or an API based deployment, so the test covers the validation boundary that matters.

Keep the assertion precise. Confirm that the five field expression is accepted and that runs occur at the intended times. If timezone handling, missed executions, or concurrency are also under review, test those separately. The release page does not attribute changes in those areas to [email protected].

This patch is a reasonable candidate for a focused rollout because its documented scope is one core bug fix. Normal backup and rollback controls still apply. In particular, preserve the prior workflow definition until the updated schedule has completed the validation window.