A scheduled report arrived at the wrong time or covered the wrong days

Whose clock runs the schedule

Two settings are easy to confuse: the clock that decides when a scheduled automation runs, and the clock that decides how times are shown to you. Zapier's schedule article says a schedule trigger uses the time zone set in your Zapier account, not the one set in the Zap, and that run times in Zap history display in UTC. After you change the account time zone you must turn the Zap off and on for it to take effect. Zapier also says it does not guarantee the precise minute; a run should land within a few minutes of the chosen time.

Make works differently. Its help centre says the organisation's time zone defines the time used when scenarios execute, while a user's time zone only changes how times appear in logs. A schedule of 4pm means 4pm in the organisation's zone, whichever country the person who built it sits in, and only organisation owners and admins can change it. Date functions that omit a time zone use the organisation's zone too.

• Find the account or organisation time zone and write it next to the schedule.
• Do not read the history's timestamps as local time until you know which zone they use.
• Ask who is allowed to change the setting and who would notice.

Clock changes: test, do not assume

On GOV.UK, UK clocks go forward at 1am on 29 March 2026 and back at 2am on 25 October 2026. On the first date one local hour does not exist, and on the second one occurs twice, so by simple arithmetic those days are 23 and 25 hours long. The two tool pages checked for this guide do not describe how a daily or weekly schedule behaves across a clock change, so this guide does not claim to know.

The safe approach is to test: put a copy of the schedule on a test destination and look at what runs on and around the change, or avoid the affected hours altogether.

• Avoid scheduling anything between about 01:00 and 03:00 local time on a change date.
• Write down, for each report, whether it should follow local clock time or a fixed offset.
• Check the first report after each change by hand.

Define the reporting period once

A report that covers the wrong days usually has a loose definition of its period. 'The last seven days' counted from the moment the job runs shifts if the job is late, and a period ending at 23:59 leaves out anything stamped in the last minute. The clean rule is a half-open window: the period starts at one named instant and ends at another, the start is included and the end is not, and both are computed once, in one named time zone, then reused by every step. Records stored in UTC must be converted before they are assigned to a local day, otherwise an evening sale lands in the wrong day.

• Name the report week, for example Monday 00:00 to the next Monday 00:00 in Europe/London.
• Compute the two instants in one step and pass them to every later step.
• Include a count of records and the window itself in the report's footer so a reader can see what it covered.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

Report week     : Monday 2026-10-05 00:00 to Monday 2026-10-12 00:00, Europe/London
Rule            : start included, end excluded
Run             : Monday 2026-10-12 08:00 local, 8 hours after the window closed
Sale at 23:59   : counted in the week that ends
Sale at 00:00   : counted in the next week
Footer shows    : window start, window end, 214 records (synthetic count)

Make a missing report visible

A report that does not arrive produces no message, so nobody knows. Add a check that does not depend on the report job itself: a second step or tool that expects the report by a set time and tells a named person if it has not arrived. Keep it simple, and keep it separate from the job so that one failure cannot silence both. The alert needs a shared recipient, not one person's inbox, and it should name the report and the time it was due.

What this guide does not cover

This guide does not check that the numbers in a report are right, or give accounting or tax advice. The paid outcome for alerts gives up to five named automations a shared failure alert with two named people, and is accepted when a deliberate failure on a copy of each reaches the shared place and both people confirm receipt. A standing service watches named automations each week and prepares corrected copies for you to switch on. Neither guarantees delivery time or round-the-clock cover.