n8n Missed Scheduled Runs: Catch Up, Skip, or Review?
A scheduled n8n workflow came back late. Decide whether to skip it, run one catch-up, or put the work through review before an old event changes a live system.
A scheduled workflow that starts late is not automatically broken. It can still be the wrong thing to run. Timing is a business rule.
Suppose a 9 AM job creates review tasks for yesterday's unassigned leads. The n8n instance is unavailable until noon. A late run may be useful. Now change the job: it sends same-day payment reminders. Replaying the missed 9 AM run at noon could send an overdue message after someone has already paid.
The question is not whether the scheduler can catch up. It is whether the business outcome is still valid.
An operator should be able to explain, before an outage occurs, what a late run may still change, which records must be re-read at the actual execution time, which dated source window it represents, and who can approve an exception when the original rule no longer fits.
Start with the current n8n version and trigger type
n8n's current durable scheduler documentation matters here. The durable scheduler is available from n8n 2.36 and is on by default from 2.45.0. It records upcoming Schedule Trigger runs before they are due. A run that is late beyond its grace period then follows the trigger's missed-execution policy. Older installations, and installations that deliberately use the legacy in-memory scheduler, do not have the same behavior.
For a Schedule Trigger using the durable scheduler, n8n offers three policies:
- Don't Run Missed Executions is the default. The missed occurrence is discarded and the schedule resumes normally.
- Run the Most Recent Missed Execution creates one catch-up run, then resumes the schedule.
- Run the Most Recent Missed Execution Per Rule creates one catch-up run for each schedule rule.
Neither catch-up option replays every missed occurrence one by one. Polling triggers are different: n8n's current documentation says they skip missed runs and resume from the next scheduled poll. The Schedule Trigger node options apply only to nodes added from n8n 2.36 onward. They take effect when the durable scheduler and its workflow-publication service are active. Check the exact n8n version, node age, scheduler configuration, trigger type, and workflow timezone before using any of these as an operating rule. The Schedule Trigger options and durable scheduler documentation are the source of truth for the version you run.
Decide from the business effect, not the clock
Use the default skip policy when a late run would make a time-bound decision with stale information. But skip is not a hard deadline: a scheduled run that starts within its effective grace period can still execute. A strict deadline needs an execution-time guard that checks whether the input and time are still valid, then routes an ineligible item to a person. A catch-up run fits a job whose outcome remains useful and safe when late.
A catch-up policy is an operating choice, not a recovery guarantee: it cannot establish that a delayed record still meets the rules that applied at its original scheduled time. Manual review is an operating process, not a fourth built-in missed-execution policy.
| Scheduled work | If it runs late | Safer default | What to verify first |
|---|---|---|---|
| Build a daily list of records missing an owner | The list is still useful, but it may contain records assigned since 9 AM | One catch-up can be reasonable | Re-read ownership at execution time and label the report with its cutoff |
| Send a payment reminder | A customer may have paid or contacted finance since the original time | Skip and review the affected set | Current payment state, hold rules, and who can approve a manual send |
| Load yesterday's approved source records into a reporting store | A late load may be fine if the window is explicit | One catch-up can be reasonable | Source watermark, duplicate protection, and report freshness marker |
| Close a time-sensitive sign-up window | Late processing changes the promised deadline | Skip, then decide manually | The policy for late entrants and the audit trail |
The table is a synthetic design exercise. It is intentionally small. It is not an observed customer workflow, a tested n8n configuration, or a recommendation to replay records blindly.
A small acceptance example: expected input versus completed outcome
For any schedule, write down the source records that should have been considered and the outcome that proves they were handled. A green n8n execution tells you that code ran. It does not prove the intended business event happened, or that a late replay remains appropriate.
Here is a deliberately small example for a daily lead-assignment report. The identifiers and outcomes are synthetic.
| Case | Expected input | Completed outcome | Acceptance decision |
|---|---|---|---|
| Normal 9 AM run | Eligible lead L-104 has no owner at the agreed cutoff |
Report contains L-104, cutoff time, and the named reviewer |
Accept after the reviewer can locate the source record |
| Instance starts at noon | The scheduled run was missed; L-104 still has no owner |
One late report is produced and marked with its actual run time | Accept only if the report is informational and current ownership is re-read |
| Instance starts at noon, owner changed at 10 AM | L-104 was eligible at 9 AM but has an owner by noon |
It is excluded or visibly marked as resolved | Do not treat the late report as proof that assignment failed |
| No report after the grace window | No completed outcome exists | An operating alert or review item names the missed window | Investigate before the next schedule hides the gap |
This is a proposed acceptance pack, not a downloadable workflow. It has not been run in n8n. Test it with synthetic records in the same runtime and scheduler mode that will operate the real workflow. Keep outbound actions disabled until the team agrees how a late run should behave. No live writes.
Configure the policy, then test the missing window
The policy is set in the Schedule Trigger's Settings tab on supported nodes. It only takes effect when the durable scheduler and its workflow-publication service are in use. The grace period determines when a late run counts as missed, so it is part of the business decision too. A five-minute grace period may fit an internal digest; it is not automatically appropriate for a daily billing task.
Test the situation you are designing for:
- Record the n8n version, trigger type, workflow timezone, scheduler mode, policy, and grace period.
- Use synthetic source records that show the difference between the original cutoff and the actual run time.
- In an isolated test instance, publish the synthetic workflow, disable all outbound actions, then simulate an instance outage and restart that crosses the effective grace period. Do not deactivate the workflow: that tests a different state.
- Verify whether the expected catch-up occurs, whether it is one run or one per rule, and how the outcome is labeled.
- Confirm the operator can see a missed window and knows whether to skip, reconcile, or manually approve it.
A local logic check is not a scheduler test. The public n8n samples were tested as credential-free samples, but they do not exercise schedule-trigger recovery or an external system.
Keep missed runs separate from failed runs
An n8n error workflow runs when an execution fails. That is useful, but it is not a complete answer for an expected event that did not become a completed outcome. Compare eligible source records, completed outputs, and unresolved exceptions on a schedule that matches the process. Then give an owner a way to find the missing window.
The n8n error-handling guide covers execution failures and safe retries. The production readiness guide has a worksheet for recording this evidence. If the policy, runtime, and ownership are still unsettled, n8n consulting can scope the decision before a delayed scheduler run turns into a live action.
Have a similar operating problem?
Tell us about the process and the decision you need to make.