Short answer: Set the workflow timezone before writing the schedule. Confirm the exact hour, weekday, and daylight-saving behavior. Run one controlled test before enabling a recurring production job.

Which timezone controls the run?

Check the workflow timezone and the instance timezone. A schedule that looks correct in the editor can run at another hour when the deployment uses a different default. Write the intended timezone beside the business rule.

Pay special attention to daylight-saving changes. A local time may skip or repeat on the transition date. If the job must run once per interval, choose a UTC schedule or add a duplicate guard.

How should a cron rule be checked?

Read each field from left to right. Confirm minute, hour, day, month, and weekday behavior for the chosen schedule type. Test the next few expected run times with a known calendar.

Do not test a production action first. Point the schedule at a log or notification node. Record the trigger time and the timezone shown in the execution.

What prevents duplicate work?

Store a run key when the workflow processes a time window. Before writing a result, check whether that key already exists. This protects against manual re-runs and repeated times during a timezone transition.

Use a small overlap window when the source system publishes late data. Make the downstream write idempotent so the overlap does not create duplicate records.

What should be verified before enabling it?

Confirm the workflow is active, the credentials work, and the first execution has the expected timestamp. Inspect the result after one scheduled run. Use the execution debugging guide when the time is correct but the result is missing.

For trigger differences, compare the schedule, webhook, and event trigger guide.