# Best Practice on Changing Scheduled Downtimes

**URL:** <https://community.icinga.com/t/best-practice-on-changing-scheduled-downtimes/12574>\
**Category:** Icinga 2\
**Created:** [September 11, 2023, 8:27am UTC](https://community.icinga.com/t/best-practice-on-changing-scheduled-downtimes/12574 "2023-09-11T08:27:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![fir3wall](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/df788c/32.png) [@fir3wall](https://community.icinga.com/u/fir3wall)\
**Post date:** [September 11, 2023, 8:27am UTC](https://community.icinga.com/t/best-practice-on-changing-scheduled-downtimes/12574/1 "2023-09-11T08:27:06Z")

</div>

Hi All,

I found this old topic:

> [@Deleting Scheduled Downtime on parent host not deleting downtime on dependent child host](https://community.icinga.com/t/deleting-scheduled-downtime-on-parent-host-not-deleting-downtime-on-dependent-child-host/11533/3):
>
> Hey Al2Klimov, thank you for your reply. Is the PR which you linked not a different topic, it sounds like the scenario: schedule downtime on host with all services on host remove downtime on host removes also the downtimes on the host services My scenario ist: parent host ↔ child host via dependency apply rule schedule downtime for parent host → downtime for child host is automatically set delete downtime of parent host → downtime of child host is not deleted automatically We use Icinga2…

But solution provided there is no good for me, so looking for some best practices.

Issue is that (please note I’m not using Director) when I change scheduled downtime object then I’m landing with 2 downtimes on my service - old one and new one. My current workaround to remove old object (as it’s runtime object) is to disable/re-enable host object.

This is not great because then when I re-enable Host object then I’m loosing history for it in IcingaWeb2 so I don’t have historical data about services etc.

Can somebody advise on better solution to refresh this in case of change?

Icinga2 version 2.13.7

Thanks  
D

---

<div class="post-metadata">

**Author:** ![Al2Klimov](https://community.icinga.com/user_avatar/community.icinga.com/al2klimov/32/959_2.png) [@Al2Klimov](https://community.icinga.com/u/Al2Klimov)\
**Post date:** [September 11, 2023, 5:18pm UTC](https://community.icinga.com/t/best-practice-on-changing-scheduled-downtimes/12574/2 "2023-09-11T17:18:08Z")

</div>

Hello Dariusz!

Don’t the old ones vanish periodically?

> <https://github.com/Icinga/icinga2/pull/8310>
>
> ... to cause their re-creation with the ScheduledDowntime change taken into acco…unt.
> 
> fixes #8309
> closes #8630
> 
> ref/NC/700763
> ref/IP/31583

Best,  
A/K

---

<div class="post-metadata">

**Author:** ![fir3wall](https://community.icinga.com/letter_avatar_proxy/v4/letter/f/df788c/32.png) [@fir3wall](https://community.icinga.com/u/fir3wall)\
**Post date:** [September 12, 2023, 4:16am UTC](https://community.icinga.com/t/best-practice-on-changing-scheduled-downtimes/12574/3 "2023-09-12T04:16:17Z")

</div>

HI @Al2Klimov

To be honest I maybe was too inpatient and observed it only for 1-3 min.

Let me keep an eye for it for a little bit more time and let you know. If yes, that’s a solution!

Thanks  
Dariusz