⚙️Automation· 3 min read· Updated Oct 2026

Define timezone and cutoff rules for recurring automations

A recurring run needs a business calendar contract, not just a time. Specify the zone, cutoff inclusion and treatment of late or missed work.

Define the business timezone, eligibility window and cutoff boundary before implementing a recurring automation. A rule such as “run daily at six” is incomplete until everyone agrees which clock, which records and which business day it refers to.

Separate run time from eligibility time

The moment a process starts need not determine which records belong in its batch. A delayed run should still have an explicit intended window rather than silently collecting a different set of work.

n8n documentation establishes workflows as connected nodes and includes execution topics. The supplied evidence does not establish scheduling defaults, timezone settings or missed-run behaviour. Treat those as implementation questions to verify.

For Indian teams, write the intended Indian business timezone explicitly instead of assuming that every participating system uses the same clock.

Complete a calendar-boundary worksheet

Record these decisions before scheduling:

  • Business zone: the named zone governing business dates and cutoffs.
  • Timestamp basis: event time, receipt time or another agreed timestamp.
  • Window boundaries: exact start and end, including which boundary is inclusive.
  • Business calendar: who maintains working days and organisation-specific closures?
  • Late arrival: which batch receives an event noticed after its cutoff?
  • Missed run: whether to catch up, combine windows or require review.
  • Repeated run: how the same window avoids duplicate side effects.
  • Reporting label: which business date appears on the output?

Record offsets or timezone information with synthetic test timestamps so reviewers do not have to guess their interpretation.

Test a hypothetical Indian cutoff

A fictional Bengaluru operations team proposes a weekday batch labelled by its closing date. Its illustrative window runs from 18:00 IST on the previous business day, inclusive, to 18:00 IST on the current business day, exclusive.

Evaluate these synthetic inputs for a Tuesday batch:

  1. Monday 18:00:00 IST: included.
  2. Tuesday 17:59:59 IST: included.
  3. Tuesday 18:00:00 IST: excluded and assigned to the next eligible window.
  4. An event timestamped Tuesday 17:50 but received at 18:10: handled by the separately agreed late-arrival rule.

Then mark Tuesday as an organisation-specific closure. Recalculate the window using the proposed calendar policy rather than assuming a public holiday rule. Finally, simulate a Wednesday catch-up run and verify that no window disappears or overlaps unintentionally.

Stop ambiguous date assignment

Stop scheduling if reviewers assign the same boundary event to different batches. Next, agree inclusivity, calendar ownership and catch-up policy, then verify implementation behaviour with synthetic timestamps.

For procurement, check the automation catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or scheduling behaviour.

Sources and scope

Source material checked 29 October 2026; features/policies may change. n8n workflow documentation establishes the connected workflow model. The calendar worksheet and IST examples are editorial specifications, not claims about platform scheduling defaults.

Compare current listings

Check the selected plan, price, availability and delivery terms before ordering.

Related reads