[GH-ISSUE #573] Send less UP/DOWN emails in a row to save money and email reputation #417

Closed
opened 2026-02-25 23:42:23 +03:00 by kerem · 3 comments
Owner

Originally created by @arxeiss on GitHub (Oct 18, 2021).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/573

Hi, I was playing with your service and I have found it amazing. However, I have found a situation, in which your service would "spam" my email.

I set up the check to 2 minutes interval and 2 minutes grace time. My cron runs every 2 minutes.
But then I misclicked the cron config and set up run every 5 minutes. And every 4th minute I received DOWN email and 1 minute later UP email. And that went again and again. I received during an hour 24 emails.

I was thinking about the best way to solve this. And I think the best idea would be to create new option for each check, which would define how many Success pings you need to convert from Down to Up. So I would put there let say 6.
So I would need to have 6x success ping without any missing or fail to go UP again.

This should avoid repeated UP/DOWN emails.

Originally created by @arxeiss on GitHub (Oct 18, 2021). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/573 Hi, I was playing with your service and I have found it amazing. However, I have found a situation, in which your service would "spam" my email. I set up the check to **2 minutes interval** and **2 minutes grace time**. My cron runs every 2 minutes. But then I misclicked the cron config and set up run every 5 minutes. And every 4th minute I received DOWN email and 1 minute later UP email. And that went again and again. I received during an hour 24 emails. I was thinking about the best way to solve this. And I think the best idea would be to create new option for each check, which would define how many `Success` pings you need to convert from Down to Up. So I would put there let say 6. So I would need to have 6x success ping without any missing or fail to go UP again. This should avoid repeated UP/DOWN emails.
kerem closed this issue 2026-02-25 23:42:23 +03:00
Author
Owner

@cuu508 commented on GitHub (Nov 3, 2021):

I think in the use case you described (Healthchecks is configured for 2 minute interval, the actual cron job runs at 5 minute interval) the correct solution would be to fix the schedule on Healthchecks side to match the cron job.

<!-- gh-comment-id:958759141 --> @cuu508 commented on GitHub (Nov 3, 2021): I think in the use case you described (Healthchecks is configured for 2 minute interval, the actual cron job runs at 5 minute interval) the correct solution would be to fix the schedule on Healthchecks side to match the cron job.
Author
Owner

@arxeiss commented on GitHub (Nov 3, 2021):

But the 5 minutes interval was bad. It should be 2 minutes, but I set up accidentally 5 minutes in crontab.

So warnings from Healthchecks were OK, just there were too many emails, cause it was DOWN and UP every 5 minutes

<!-- gh-comment-id:958770195 --> @arxeiss commented on GitHub (Nov 3, 2021): But the 5 minutes interval was bad. It should be 2 minutes, but I set up accidentally 5 minutes in crontab. So warnings from Healthchecks were OK, just there were too many emails, cause it was DOWN and UP every 5 minutes
Author
Owner

@cuu508 commented on GitHub (Nov 3, 2021):

OK, the correct solution would be to fix the cron job's schedule.

I don't think adding additional configuration option is the way to go here. For the configuration option to work, the user would need to know it exists. The user would need to understand precisely how it works. The user would need to care to set this option to a reasonable value. And there's significant technical cost to implementing it.

OTOH, sending 2000 emails to an user over 24h period in some rare cases is not a significant cost or reputation issue. As an user, bulk deleting the notifications from the past 24h shouldn't be too hard either, and the user shouldn't need to do this often.

I think we can leave this as-is.

<!-- gh-comment-id:958807468 --> @cuu508 commented on GitHub (Nov 3, 2021): OK, the correct solution would be to fix the cron job's schedule. I don't think adding additional configuration option is the way to go here. For the configuration option to work, the user would need to know it exists. The user would need to understand precisely how it works. The user would need to *care* to set this option to a reasonable value. And there's significant technical cost to implementing it. OTOH, sending 2000 emails to an user over 24h period in some rare cases is not a significant cost or reputation issue. As an user, bulk deleting the notifications from the past 24h shouldn't be too hard either, and the user shouldn't need to do this often. I think we can leave this as-is.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/healthchecks#417
No description provided.