A scheduled supplier fetch runs at the wrong time, twice or not at all: time zones, clock changes and cron surprises

The same line means different things on different hosts

A schedule such as 30 2 * * * means 02:30 in whatever time zone the scheduler uses. If your server is set to UTC and your supplier publishes at 02:00 in London, the file is an hour earlier or later than you think for half the year. The manual for cronie, the cron implementation this guide cites throughout, says a crontab can name its own zone with CRON_TZ, and that log timestamps still use the daemon's local zone, which can make a log look an hour wrong when the job was correct. Debian's manual site also lists bcron, cron and systemd-cron as other packages with a crontab(5) manual page, so another implementation on your host may behave differently; check which one yours is.

Clock changes add a second trap, and the cronie manual describes it in two places that read differently. Its cron(8) page says changes of under three hours are handled in a special way for jobs that run at a specific time or with a granularity greater than one hour: when the clock goes forward, jobs in the skipped interval are run immediately, and when it goes back, running the same job twice is avoided. Its crontab(5) page says that times that do not exist, such as the missing hours in a daylight saving conversion, never match, so jobs scheduled in them are not run, and that times that occur more than once cause matching jobs to be run twice. Those two descriptions do not agree, and neither page says how they fit together. So do not rely on either: test what your host does on a clock-change date, or make the job safe whichever way it behaves, as below.

• Check the host's time zone and the time zone of the supplier's publication time separately.
• Write the time zone beside every schedule in your run book.

Surprises in the schedule itself

Two more cron details cause real faults, and these also come from the cronie crontab(5) manual. When both the day-of-month and the day-of-week fields are restricted, the job runs when either one matches, so 0 3 1 * 1 runs on the first of the month and also every Monday. And an unescaped percent sign in the command is changed into a newline, which truncates a command that builds a date stamp such as date +%Y%m%d; a backslash in front of each percent sign avoids it. Cron also runs commands with a small environment: SHELL is set to sh, and HOME and LOGNAME are set from the owner's account entry, so a job that works in your terminal can fail from the schedule for lack of a path or setting.

Output goes by mail to the crontab's owner unless MAILTO names another address, and an empty MAILTO sends no mail. A job that fails every night with its output going to an unread mailbox is one way a stopped fetch goes unnoticed.

Make the job safe whichever way the schedule behaves

The reliable answer is not a cleverer schedule but a job that cannot do harm if it runs twice, late or not at all. First, record what has been imported, so a repeat run finds nothing new. Second, fetch only complete files, so a run that is early finds nothing finished. Third, take a lock so a second run that starts while the first is still working exits at once, rather than importing the same file in parallel; any single-instance locking method does the job and it should be tested. Fourth, raise an alert when no new file has arrived by an agreed time, so a missed run is a visible event. These are our recommendations; they are engineering practice rather than statements from the manuals cited.

• Prefer a schedule in one fixed zone, and avoid the hours around a local clock change.
• If both a fixed daily run and a day-of-week rule are needed, write them as separate lines.

Other diagnoses to rule out

A job that did not run may not be a scheduler fault. The server may have been off, a disk full, the file not published yet, the supplier's address allow-list changed or a credential rotated. Check the job's own log for an entry at the expected time before blaming the schedule, and compare the supplier's publication time with the run time in the same zone.

How the paid job is accepted

The scheduling rule is part of the written scope of the job sftp-scheduled-supplier-fetch-complete-files, which starts from £445. It is tested against a synthetic server: the finished file is imported once, a repeat imports nothing, a second run started while the first is still fetching imports nothing twice, a changed host key stops the job and a missing file raises the agreed alert. We do not run your live scheduler or hold your credentials; your maintainer applies the change. If your problem is only the cron line itself, a short conversation or your host's documentation may serve you better than a paid job. Prices are untested proposals, and payment follows the agreed checks and your sign-off. Nothing is booked or charged by an enquiry.