mirror of
https://github.com/healthchecks/healthchecks.git
synced 2026-04-25 15:05:49 +03:00
[GH-ISSUE #1171] [Feature Request] differentiate between “down” and “grace period reached” alerts #805
Labels
No labels
bug
bug
bug
feature
good-first-issue
new integration
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/healthchecks#805
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sebguilbaud on GitHub (Jun 4, 2025).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1171
in the case of high-frequency job monitoring (execution every minute), we're more interested in the grace period expiring, rather than an error, knowing that the job will be restarted in the next minute, it would be useful to have two levels of notification in healthchecks
@cuu508 commented on GitHub (Jun 4, 2025):
Notifications via most channels do differentiate between the two.
For example, Slack notification when grace time has run out:
And when the failure signal has been received:
@sebguilbaud commented on GitHub (Jun 4, 2025):
sorry I wasn't specific enough, I'd like to be able to choose the types of notifications to send, like for example disabling notifications on fail but leaving them on grace time exceeded
@cuu508 commented on GitHub (Jun 4, 2025):
Ah, I see. This would be a niche feature, but would add complexity to the UI and the code, and to user's mental model of how the system works. I'm currently not planning to work on this, but a workaround you could consider would be to not send the /fail signals to Healthchecks at all. On success, report success. On failure, either report nothing or use the log endpoint.