Twice a year a scheduled rule that has worked for months starts firing an hour early or an hour late. Nothing was changed. This is the reason, and it is documented.
A cron expression in a Jira automation scheduled trigger is evaluated in UTC.
UTC does not observe daylight saving. Your office does. So a rule written as
0 8 * * 1-5 fires at 08:00 UTC all year, which in Berlin is 09:00 in winter and
10:00 in summer, and in New York 03:00 and 04:00.
Atlassian has an open suggestion to change this — AUTO-1712, “Improve scheduled trigger: Include timezone support for Cron jobs”, raised in February 2025 and still at Gathering Interest when we last read it on 14 September 2026. Its own description says that administrators have to adjust their schedules manually every six months, and that support teams get complaints when triggers miss their stated time across a daylight-saving change.
The related, much older AUTO-101 — which asked for start times, business days and timezone support together — is closed and deployed. Parts of it shipped. The timezone part is the piece that did not.
Open the rule, go to Audit log, and read the timestamps of the last few runs rather than the schedule you intended. Then compare a run from before the last clock change with one from after. If the gap between them is exactly one hour, this is your problem. If it is a few minutes, it is queueing and not timezones — scheduled rules are dispatched, not guaranteed to the second, on any platform including ours.
The scheduled trigger can run at a fixed rate — every day, every 7 days — from a start date and time you pick, and that form behaves the way people expect. If your requirement is “every weekday morning” rather than “08:00 exactly”, this is the least work and it is free. It is also the part of AUTO-101 that Atlassian actually shipped.
Where it runs out: “the last Friday of the month”, “every second Tuesday”, and anything that has to skip a public holiday. Those need cron, and cron brings UTC back with it.
Unsatisfying, free, and completely reliable as long as somebody remembers. If you take this route, put the two clock-change dates in a calendar with the rule name in the title, because the failure is silent — the rule does not error, it just runs at the wrong time, and the person who notices is whoever was waiting for the ticket.
Schedule the rule to run every hour, then add a condition that compares the current local time against the time you actually want, and stops the rule otherwise. Jira's date and time smart values can format a date in a named timezone, so the comparison can be made in local terms even though the trigger is not.
This works. Be aware of what it costs: the rule is now executing twenty-four times a day instead of once, and from December 2026 Atlassian bills automation by consumed steps, so a guard that runs hourly on a busy site is not free in the way it used to be. Check the current pricing yourself before committing to this one — Atlassian's automation trigger documentation is the place to start.
The underlying distinction is worth understanding whatever you choose: +01:00 is
an offset and Europe/Berlin is a timezone. An offset is a
number that was correct once. A timezone is a rule that is re-evaluated against the calendar
every time you ask it. Anything that stores the first and calls it the second will be wrong
twice a year, forever, and no amount of testing in October will show it.
That is the difference to look for in any tool you evaluate, ours included: ask whether it stores a named zone and resolves it at run time, or stores an offset at the moment you saved the job. If the answer is not in the documentation, it is worth one support email before you buy.
In most of Europe the clocks change on the last Sunday of March and the last Sunday of October, and in North America on different dates. A site with people in both will have a two-week window every spring and autumn where the two are out of step with each other. A monthly job that has run correctly for a year can land in that window once and fire on the wrong day, not merely at the wrong hour, if the day boundary moves across midnight. Test the two nights a year, not an ordinary Tuesday.
We build Recurring Issues & Reminders for Jira, which is one of the options above. We have tried to write this page so it is useful to somebody who picks one of the other ones — if the automation rule does what you need, use the automation rule.
Something here wrong or out of date? [email protected]. Written reply, one business day, and corrections go up with the date on them.