A scheduled task sounds simple until the business operates across locations or a run is delayed. Send the report at nine can mean nine in the head office, nine for each branch or a fixed technical time. The application needs an explicit interpretation. Australian businesses should make location-based timing a first-class part of scheduling rather than relying on a server's default clock.
Name the business time zone
Imagine a wholesaler sending each branch its morning dispatch list. A branch in Adelaide and a branch in Brisbane should receive the report according to the business's agreed local schedule, which may vary through the year. Store a named time-zone rule appropriate to the location rather than treating a current offset as a permanent rule. MDN's Intl.DateTimeFormat documentation supports explicit time-zone formatting for display. Scheduling itself also needs a capable implementation, with documented behaviour around clock changes and times that may be repeated or skipped.
Distinguish a scheduled time from a completed run
A task intended for nine may start late because a service is unavailable or a queue is busy. Record the intended run time, actual start and outcome. Give each run an identifier so staff can investigate a missing report or repeated action. Decide whether a late report is still useful, whether it should be skipped after a cutoff and whether the next run includes the missed period. Those choices depend on the task. A daily information summary and an action that changes stock should not inherit the same catch-up behaviour without review.
Make retries safe for the business action
A failed task may have completed part of its work before the failure became visible. A retry should recognise completed items instead of repeating every action blindly. For a dispatch report, that may mean avoiding duplicate sends. For a data update, it may mean recording the items already processed. Set a stopping point for automatic retries and send unresolved runs to a named owner. Include a manual-run option only with clear scope, so an administrator can tell whether they are rerunning today's job or processing an older missed period.
Rehearse a missed morning
Use a test schedule to simulate downtime across the expected run time, then restore the service. Check what runs, what is skipped and what staff can see. Before relying on the automation, agree:
- The business location and named time zone for each schedule.
- The treatment of daylight-saving changes and delayed starts.
- The catch-up and duplicate-prevention rules.
- The owner of failed runs and the meaning of any manual rerun control.