[GH-ISSUE #870] Integration Request: Webook running and stopped trigger similar to "hc_check_started" #612

New issue

Closed

opened 2026-02-25 23:43:01 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @tekert on GitHub (Jul 31, 2023).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/870

This is a proposal to send webhooks when a check is running (initiated with /start) and ended with a ping.
Prometheus integration labels this as a metric named hc_check_started

Currently webhook only supports health checks triggers (UP or DOWN) status.

The proposal is to add another trigger for checks that are started and when they are stopped (finished)
This is useful for sending push metrics without having to scrape prometheus endpoint at increased intervals for example, causing strain at both ends.

It would also be useful to have a placeholder for the unique_key that's exposed for the prometheus metric in the webhook, it's doesn't seem to be a uuid or I'm mistaken?

Originally created by @tekert on GitHub (Jul 31, 2023). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/870 This is a proposal to send webhooks when a check is running (initiated with `/start`) and ended with a ping. Prometheus integration labels this as a metric named `hc_check_started` Currently webhook only supports health checks triggers (UP or DOWN) status. The proposal is to add another trigger for checks that are `started` and when they are `stopped` (finished) This is useful for sending push metrics without having to scrape prometheus endpoint at increased intervals for example, causing strain at both ends. It would also be useful to have a placeholder for the` unique_key` that's exposed for the prometheus metric in the webhook, it's doesn't seem to be a `uuid` or I'm mistaken?

kerem closed this issue

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

kerem commented

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

Author

Owner

@cuu508 commented on GitHub (Aug 1, 2023):

Thanks for the suggestion!

The job of Healthchecks is to notify you when a job does not run or time. All notification methods, including webhooks, notify you on state changes (up -> down, and down -> up). They do not notify on "success" events, they do not notify on repeated "fail" events.

Notifying on "start" and "success" events would effectively be pass-through: when an event comes in, Healthchecks forwards it to the designated webhook address. I suggest you bypass Healthchecks and push from the client to the webhook target directly. If you also want Healthchecks monitoring, you could set up the client to ping Healthchecks and the webhook target in two separate HTTP requests.

@cuu508 commented on GitHub (Aug 1, 2023): Thanks for the suggestion! The job of Healthchecks is to notify you when a job does not run or time. All notification methods, including webhooks, notify you on state changes (up -> down, and down -> up). They do not notify on "success" events, they [do not notify on repeated "fail" events](https://github.com/healthchecks/healthchecks/issues/691). Notifying on "start" and "success" events would effectively be pass-through: when an event comes in, Healthchecks forwards it to the designated webhook address. I suggest you bypass Healthchecks and push from the client to the webhook target directly. If you *also* want Healthchecks monitoring, you could set up the client to ping Healthchecks and the webhook target in two separate HTTP requests.