[GH-ISSUE #1109] [Feature Request] Add Holiday Support to Check Status Logic

kerem commented

2026-02-25 23:43:31 +03:00

Owner

Originally created by @LucianoVandi on GitHub (Dec 25, 2024).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1109

Currently, the get_status method in the Check model determines the status of a check based on its timing and grace period. However, there is no built-in support to account for public holidays, which can lead to unnecessary "down" statuses for checks expected to run on working days only.

Proposal

Introduce a feature that allows a check to ignore "down" statuses on public holidays. This could involve:

Adding an ignore_holidays flag to the Check model.
Modifying the get_status method to skip status transitions if ignore_holidays is true and the current day is a public holiday.
Providing a way to specify the country or region whose public holidays should be considered, as public holidays vary across locations.

Notes

This is just an initial idea to gather feedback and explore feasibility. I'm open to suggestions on how best to implement this feature or alternative approaches to achieve similar functionality.

Originally created by @LucianoVandi on GitHub (Dec 25, 2024). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1109 Currently, the `get_status` method in the `Check` model determines the status of a check based on its timing and grace period. However, there is no built-in support to account for public holidays, which can lead to unnecessary "down" statuses for checks expected to run on working days only. ### **Proposal** Introduce a feature that allows a check to ignore "down" statuses on public holidays. This could involve: 1. Adding an `ignore_holidays` flag to the `Check` model. 2. Modifying the `get_status` method to skip status transitions if `ignore_holidays` is `true` and the current day is a public holiday. 3. Providing a way to specify the country or region whose public holidays should be considered, as public holidays vary across locations. ### **Notes** This is just an initial idea to gather feedback and explore feasibility. I'm open to suggestions on how best to implement this feature or alternative approaches to achieve similar functionality.

kerem closed this issue

2026-02-25 23:43:31 +03:00

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 26, 2024):

Can you please describe your use case? Why are there no pings on public holidays?

@cuu508 commented on GitHub (Dec 26, 2024): Can you please describe your use case? Why are there no pings on public holidays?

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@LucianoVandi commented on GitHub (Dec 26, 2024):

@cuu508 thank you for your response!

The use case revolves around monitoring jobs that are executed exclusively on business days and not during public holidays. A practical example would be the transmission of sales data to suppliers, which occurs only from Monday to Friday on working days. These jobs are deliberately skipped during holidays to align with the operational schedules of both the organization and the suppliers.

@LucianoVandi commented on GitHub (Dec 26, 2024): @cuu508 thank you for your response! The use case revolves around monitoring jobs that are executed exclusively on business days and not during public holidays. A practical example would be the transmission of sales data to suppliers, which occurs only from Monday to Friday on working days. These jobs are deliberately skipped during holidays to align with the operational schedules of both the organization and the suppliers.

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 26, 2024):

Hey @LucianoVandi, use cron schedule and specify MON-FRI in the weekday field.

@cuu508 commented on GitHub (Dec 26, 2024): Hey @LucianoVandi, use cron schedule and specify MON-FRI in the weekday field.

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@LucianoVandi commented on GitHub (Dec 26, 2024):

@cuu508 thanks for the suggestion.

I’m already using a cron schedule to ensure the checks are only expected to run on weekdays (MON-FRI). However, the issue arises with public holidays, which are not accounted for in a standard cron schedule. For example, if Christmas falls on a Wednesday, the system will still expect a ping, and if none is received, it will mark the check as "down."

@LucianoVandi commented on GitHub (Dec 26, 2024): @cuu508 thanks for the suggestion. I’m already using a cron schedule to ensure the checks are only expected to run on weekdays (MON-FRI). However, the issue arises with public holidays, which are not accounted for in a standard cron schedule. For example, if Christmas falls on a Wednesday, the system will still expect a ping, and if none is received, it will mark the check as "down."

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 26, 2024):

Can you please give me a specific example (your use case, not a hypothetic example use case) – what system is sending the pings? Why is it not sending pings on public holidays? Does somebody physically turn it off during holidays?

@cuu508 commented on GitHub (Dec 26, 2024): Can you please give me a specific example (*your* use case, not a hypothetic example use case) – what system is sending the pings? Why is it not sending pings on public holidays? Does somebody physically turn it off during holidays?

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@LucianoVandi commented on GitHub (Dec 26, 2024):

The example I provided is not hypothetical but represents a real use case in our environment. Here's the scenario:

We are monitoring a system responsible for transmitting sales information to suppliers. This process is controlled by a cron job running on a Linux server, scheduled to execute Monday through Friday. However, the actual execution depends on whether the current day is a "business day" (excluding public holidays).

The script executed by the cron job:

Checks if "today" is a business day.
If it is a business day:
- Attempts to send the sales information.
- Sends a ping to the health check endpoint upon successful transmission, or a failure ping if the transmission fails.
If it is not a business day:
- Does nothing: no sales information is transmitted, and no pings are sent to the health check.

This behavior is intentional, as the application logic assumes no transactions or communications with suppliers on non-business days. Additionally, we have other scenarios where business day behavior matters.

For instance: we would like to add a health check to monitor the presence and processing of a specific message in a message queue. This message is added to the queue as a result of an operator's action. On public holidays, since no operators are available, no messages are added to the queue, and consequently, no processing occurs.

@LucianoVandi commented on GitHub (Dec 26, 2024): The example I provided is not hypothetical but represents a real use case in our environment. Here's the scenario: We are monitoring a system responsible for transmitting sales information to suppliers. This process is controlled by a cron job running on a Linux server, scheduled to execute Monday through Friday. However, the actual execution depends on whether the current day is a "business day" (excluding public holidays). The script executed by the cron job: - Checks if "today" is a business day. - If it **is** a business day: - Attempts to send the sales information. - Sends a ping to the health check endpoint upon successful transmission, or a failure ping if the transmission fails. - If it **is not** a business day: - Does nothing: no sales information is transmitted, and no pings are sent to the health check. This behavior is intentional, as the application logic assumes no transactions or communications with suppliers on non-business days. Additionally, we have other scenarios where business day behavior matters. For instance: we would like to add a health check to monitor the presence and processing of a specific message in a message queue. This message is added to the queue as a result of an operator's action. On public holidays, since no operators are available, no messages are added to the queue, and consequently, no processing occurs.

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 26, 2024):

Thanks for the additional detail.

Have you considered changing the script to something like:

Checks if "today" is a business day.
If it is a business day:
- Attempts to send the sales information.
- Sends a ping to the health check endpoint upon successful transmission, or a failure ping if the transmission fails.
If it is not a business day:
- Does not send sales information. Sends a ping to the success health check endpoint.

The idea being, even on holiday the script ran, and did what it was supposed to do (nothing), and so it signals success.

@cuu508 commented on GitHub (Dec 26, 2024): Thanks for the additional detail. Have you considered changing the script to something like: - Checks if "today" is a business day. - If it **is** a business day: - Attempts to send the sales information. - Sends a ping to the health check endpoint upon successful transmission, or a failure ping if the transmission fails. - If it **is not** a business day: - Does not send sales information. **Sends a ping to the success health check endpoint.** The idea being, even on holiday the script ran, and did what it was supposed to do (nothing), and so it signals success.

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@LucianoVandi commented on GitHub (Dec 26, 2024):

Thank you for the suggestion. This approach would indeed work in the case of the ping sent by the cron job. Even on public holidays, the script could signal "success" because it "ran and did nothing." However, there are a couple of concerns:

Non-realistic Reporting: The health check would log a "success" ping even when the actual business logic was not executed. This creates a disconnect between the reality of the system's state and the health check logs, making the logs less useful for troubleshooting or auditing.
Doesn't Cover All Scenarios: This approach works well for cron-based jobs where we control the logic that sends pings. However, it fails in other scenarios, such as my second example:
- In this case, the health check monitors the processing of a job in a message queue. A ping is sent only when an operator actively processes the job. On public holidays, no jobs are queued or processed, so no pings are sent.

Alternatively, if this feat-request is not deemed necessary, I was thinking of handling these cases with an external script that adjusts the grace period via the API based on a specific tag. This would allow for dynamic adjustments depending on the scenario, such as extending the grace period for checks tagged with something like holiday-tolerant to account for public holidays.

@LucianoVandi commented on GitHub (Dec 26, 2024): Thank you for the suggestion. This approach would indeed work in the case of the ping sent by the cron job. Even on public holidays, the script could signal "success" because it "ran and did nothing." However, there are a couple of concerns: 1. **Non-realistic Reporting**: The health check would log a "success" ping even when the actual business logic was not executed. This creates a disconnect between the reality of the system's state and the health check logs, making the logs less useful for troubleshooting or auditing. 2. **Doesn't Cover All Scenarios**: This approach works well for cron-based jobs where we control the logic that sends pings. However, it fails in other scenarios, such as my second example: - In this case, the health check monitors the processing of a job in a message queue. A ping is sent only when an operator actively processes the job. On public holidays, no jobs are queued or processed, so no pings are sent. Alternatively, if this feat-request is not deemed necessary, I was thinking of handling these cases with an external script that adjusts the `grace` period via the API based on a specific tag. This would allow for dynamic adjustments depending on the scenario, such as extending the `grace` period for checks tagged with something like `holiday-tolerant` to account for public holidays.

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 27, 2024):

First of all, please do not use AI tool to write or rewrite your messages. I'm left guessing what was your original input and what is dreamed up by AI. I'm volunteering my time here, and you are feeding slop to me. This is disrespectful and very insulting. Please do not do that.

Regarding non-realistic reporting. Even on holidays, all business logic that was supposed to run, did run. Or, to put it another way, would you not want to monitor if the "is this a public holiday" part of the script did run? If there's radio silence on holidays, how do you know it ran at all? Note that you can also can track script run time and submit job logs to aid troubleshooting.
Regarding the message queue monitoring: the queue itself is not able to ping Healthchecks. You would presumably have some script that looks for messages on the queue and pings Healthchecks. You could put the "is this a public holiday" logic in that script.

As your original issue mentions, public holidays vary across locations. They also vary across time – the set of public holidays in a given location can be different each year. They also vary from company to company, companies can and do make exceptions – "we don't work on public holidays, except this one special case" or "we will relocate this working day to this Saturday", or "we obey the public holidays of country A plus country B". And so on. It is not feasible for Healthchecks to figure out what set of days (or, more precisely, datetime ranges) are "public holidays" in every individual case.

@cuu508 commented on GitHub (Dec 27, 2024): First of all, please do not use AI tool to write or rewrite your messages. I'm left guessing what was your original input and what is dreamed up by AI. I'm volunteering my time here, and you are feeding slop to me. This is disrespectful and very insulting. Please do not do that. * Regarding non-realistic reporting. Even on holidays, all business logic that was supposed to run, did run. Or, to put it another way, would you not want to monitor if the "is this a public holiday" part of the script did run? If there's radio silence on holidays, how do you know it ran at all? Note that you can also can [track script run time](https://healthchecks.io/docs/measuring_script_run_time/) and [submit job logs](https://healthchecks.io/docs/attaching_logs/) to aid troubleshooting. * Regarding the message queue monitoring: the queue itself is not able to ping Healthchecks. You would presumably have some script that looks for messages on the queue and pings Healthchecks. You could put the "is this a public holiday" logic in that script. As your original issue mentions, public holidays vary across locations. They also vary across time – the set of public holidays in a given location can be different each year. They also vary from company to company, companies can and do make exceptions – "we don't work on public holidays, except this one special case" or "we will relocate this working day to this Saturday", or "we obey the public holidays of country A *plus* country B". And so on. It is not feasible for Healthchecks to figure out what set of days (or, more precisely, datetime ranges) are "public holidays" in every individual case.

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@LucianoVandi commented on GitHub (Dec 27, 2024):

First of all, I want to assure you that my intent has never been to disrespect your time or contributions.

I'm sorry if the use of ai-tools to refine my communication has been frustrating. My only intention was to improve my English, which isn’t very good. I can assure you that this message is simply a translation of a detailed message originally written in my native language.

That said, I understand your perspective, but just as you find my use of AI tools inappropriate, I believe your approach could also be reconsidered.

I do understand and respect your reasoning for not finding it feasible to implement this logic, and I appreciate you taking the time to explain it. Thanks again for your time!

@LucianoVandi commented on GitHub (Dec 27, 2024): First of all, I want to assure you that my intent has never been to disrespect your time or contributions. I'm sorry if the use of ai-tools to refine my communication has been frustrating. My only intention was to improve my English, which isn’t very good. I can assure you that this message is simply a translation of a detailed message originally written in my native language. That said, I understand your perspective, but just as you find my use of AI tools inappropriate, I believe your approach could also be reconsidered. I do understand and respect your reasoning for not finding it feasible to implement this logic, and I appreciate you taking the time to explain it. Thanks again for your time!

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 27, 2024):

Thanks for clarifying. I will happily accept spelling and grammar mistakes as long as the meaning comes across. I also don't mind direct machine translation. But in this case the AI completely rewrote the text, changed sentence structure, and I suspect added bits that were not in the original. That is not acceptable.

@cuu508 commented on GitHub (Dec 27, 2024): Thanks for clarifying. I will happily accept spelling and grammar mistakes as long as the meaning comes across. I also don't mind direct machine translation. But in this case the AI completely rewrote the text, changed sentence structure, and I suspect added bits that were not in the original. That is not acceptable.

kerem commented

2026-02-25 23:43:32 +03:00

Author

Owner

@LucianoVandi commented on GitHub (Dec 27, 2024):

Let me remark a point: the messages I sent you are a faithful translation of what I originally wrote in my native language. I’m sorry that you still have doubts, but I assure you that the content has not been altered from its original meaning. If you choose to see it differently, that’s entirely up to you. I will continue to respect your point of view, as much as I respect your work with Healthchecks.

Have a great day, and all the best.

@LucianoVandi commented on GitHub (Dec 27, 2024): Let me remark a point: the messages I sent you are a faithful translation of what I originally wrote in my native language. I’m sorry that you still have doubts, but I assure you that the content has not been altered from its original meaning. If you choose to see it differently, that’s entirely up to you. I will continue to respect your point of view, as much as I respect your work with Healthchecks. Have a great day, and all the best.

Rows
Columns

[GH-ISSUE #1109] [Feature Request] Add Holiday Support to Check Status Logic #769

Proposal

Notes