Werk #22241: Recurring downtimes started at the wrong time or on the wrong day
| Component | Core & setup | ||
| Title | Recurring downtimes started at the wrong time or on the wrong day | ||
| Date | Oct 12, 2026 | ||
| Level | Prominent Change | ||
| Class | Bug Fix | ||
| Compatibility | Compatible - no manual interaction needed | ||
| Checkmk versions & editions |
|
Recurring downtimes could start at the wrong time or on the wrong day, and some skipped whole months. The core computed each repetition from the one before it, so a single wrong step carried over into every later repetition. The core now computes every repetition from the first start. What went wrong depended on how the downtime repeats.
All types except hour
When the clocks spring forward, they skip the hour from 02:00 to 03:00 in Central Europe. A downtime that started in that hour moved an hour earlier and stayed there: a daily downtime at 02:30 started at 01:30 from then on. Downtimes at other times kept their time. Such a downtime now starts at 03:00 on the day of the change and is back at 02:30 for the next repetition.
A remote site in another time zone repeated downtimes from the rulesets Recurring downtimes for hosts and Recurring downtimes for services in its own time zone, so these downtimes started an hour early or late for part of the year. A downtime entered for 07:30 in Berlin, for example, started at 06:30 Berlin time on a remote site in UTC once the clocks fell back. These downtimes now repeat in the time zone of the site where you configure the rules, which in a distributed setup is the central site.
Hour
When the clocks fall back in Central Europe, 02:00 comes twice: first in summer time (CEST), then an hour later in winter time (CET). An hourly downtime started at 02:00 CEST and next at 03:00 CET, two hours later. It now also starts at 02:00 CET.
Same nth weekday (from beginning)
A downtime that started within an hour of midnight could move to another weekday. One in the hour before midnight moved a day earlier each time the clocks sprang forward, and one in the hour after midnight moved a day later each time they fell back. A downtime set for the third Saturday at 23:00 in 2022 ran on a Wednesday by 2025. These downtimes now keep their weekday.
A downtime on the fifth weekday, such as the fifth Friday, skipped the first month without one and continued on the first Friday. It now falls on the fourth Friday in months without a fifth.
Same nth weekday (from end)
Downtimes within an hour of midnight moved to another weekday, as described above, and now keep their weekday. A downtime on the last weekday of the month, such as the last Friday, also skipped a month about once a year. It now repeats every month.
Same day of the month
A downtime on the 29th, 30th or 31st repeated on the 28th. It now repeats on its own day, and on the last day of shorter months. The Schedule downtimes command now also accepts these days; before, it accepted only the 1st to the 28th.
Minimal to no action needed
Downtimes from the rulesets Recurring downtimes for hosts and Recurring downtimes for services return to their schedule on their own after the update, so you don't need to change your rules.
The only exception is a recurring downtime you scheduled with the Schedule downtimes command: it keeps any shift it already has. To correct it, remove it and schedule it again.