starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 15:05:49 +03:00

[GH-ISSUE #249] Feature Request: Add other verbs for webhooks, plus separate post data for up / down endpoints #182

New issue

Closed

opened 2026-02-25 23:41:29 +03:00 by kerem · 6 comments

kerem commented

2026-02-25 23:41:29 +03:00

Owner

Originally created by @Grayda on GitHub (May 4, 2019).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/249

I've got a status page running Cachet and would like to use Healthchecks with that, however updating a component in Cachet requires a PUT request, and HC only supports GET and POST.

I think it'd be handy to have a drop-down to be able to pick PUT, or PATCH or whatever method you needed.

Also right now the up and down endpoints share the same POST data. It'd be useful to have separate data, as you may want to do something like {"message": "This check is working"}" for up events, and {"message": "This check is not working"}", for down events.

Originally created by @Grayda on GitHub (May 4, 2019). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/249 I've got a status page running [Cachet](https://cachethq.io) and would like to use Healthchecks with that, however updating a component in Cachet requires a `PUT` request, and HC only supports `GET` and `POST`. I think it'd be handy to have a drop-down to be able to pick `PUT`, or `PATCH` or whatever method you needed. Also right now the up and down endpoints share the same POST data. It'd be useful to have separate data, as you may want to do something like `{"message": "This check is working"}" for up events, and `{"message": "This check is not working"}", for down events.

kerem closed this issue

2026-02-25 23:41:29 +03:00

kerem commented

2026-02-25 23:41:30 +03:00

Author

Owner

@cuu508 commented on GitHub (May 20, 2019):

Thanks for the suggestion!

I'm thinking about how to implement this from the UI perspective, without making the "Add Webhook" form too complex. Here's an idea I'm considering:

Basically, this adds the HTTP method selector.

It doesn't have separate "Request body" fields for "down" and "up" events still. But a workaround for that could be adding two webhook integrations: one for signalling the "down" events and the other one for signalling the "up" events. The integrarations can then have different request bodies and different request headers.

How does that sound?

@cuu508 commented on GitHub (May 20, 2019): Thanks for the suggestion! I'm thinking about how to implement this from the UI perspective, without making the "Add Webhook" form too complex. Here's an idea I'm considering: ![image](https://user-images.githubusercontent.com/661859/58049546-c8094c80-7b55-11e9-8e87-5eecc80b8b1c.png) Basically, this adds the HTTP method selector. It doesn't have separate "Request body" fields for "down" and "up" events still. But a workaround for that could be adding two webhook integrations: one for signalling the "down" events and the other one for signalling the "up" events. The integrarations can then have different request bodies *and* different request headers. How does that sound?

kerem commented

2026-02-25 23:41:30 +03:00

Author

Owner

@cuu508 commented on GitHub (May 20, 2019):

And the (quick and dirty) alternative with two forms side by side:

@cuu508 commented on GitHub (May 20, 2019): And the (quick and dirty) alternative with two forms side by side: ![image](https://user-images.githubusercontent.com/661859/58050937-72cf3a00-7b59-11e9-8409-b8fe99696b2e.png)

kerem commented

2026-02-25 23:41:30 +03:00

Author

Owner

@Grayda commented on GitHub (May 20, 2019):

(I didn't realize I'd opened this request previously. I knew I'd written it, but forgot I actually hit send. Whoops!)

The UI you mocked up is what I had in mind (I had a drop-down instead of radio buttons, but they're different paths to the same end), so that's all good.

Also the two webhooks never occurred to me. I might use that instead, but if you were to go for the separate up / down data, I thought of a checkbox that would reveal a second textbox that would let you opt-in to using the up / down data. Here's my two-second devtools edit:

Not perfect of course, but that's what sprung to mind when thinking about it.

@Grayda commented on GitHub (May 20, 2019): (I didn't realize I'd opened this request previously. I knew I'd written it, but forgot I actually hit send. Whoops!) The UI you mocked up is what I had in mind (I had a drop-down instead of radio buttons, but they're different paths to the same end), so that's all good. Also the two webhooks never occurred to me. I might use that instead, but if you were to go for the separate up / down data, I thought of a checkbox that would reveal a second textbox that would let you opt-in to using the up / down data. Here's my two-second devtools edit: ![image](https://user-images.githubusercontent.com/4891563/58057955-5d363080-7baa-11e9-86ba-e5ebf73008d4.png) Not perfect of course, but that's what sprung to mind when thinking about it.

kerem commented

2026-02-25 23:41:30 +03:00

Author

Owner

@cuu508 commented on GitHub (May 27, 2019):

One limitation with my first mockup and yours as well is that both the "up" and "down" events have to use the same headers.

The second mockup with separate "Execute when down" and "Execute when up" takes care of that, but looks more cluttered. I tried to simplify it a bit:

Here user enters header key-value pairs in a textarea. Not as fancy as the current form, but is cleaner visually, is easier to implement, and probably is also easier to use in practice – less pointing and clicking to enter several headers & values.

@cuu508 commented on GitHub (May 27, 2019): One limitation with my first mockup and yours as well is that both the "up" and "down" events have to use the same headers. The second mockup with separate "Execute when down" and "Execute when up" takes care of that, but looks more cluttered. I tried to simplify it a bit: ![image](https://user-images.githubusercontent.com/661859/58438708-d832a600-80d8-11e9-9fe0-8ad7abca8087.png) Here user enters header key-value pairs in a textarea. Not as fancy as the current form, but is cleaner visually, is easier to implement, and probably is also easier to use in practice – less pointing and clicking to enter several headers & values.

kerem commented

2026-02-25 23:41:30 +03:00

Author

Owner

@cuu508 commented on GitHub (May 28, 2019):

The HTTP PUT method, and separate request bodies for "up" and "down" events are now implemented and deployed. @Grayda, feel free to test these changes out with Cachet!

@cuu508 commented on GitHub (May 28, 2019): The HTTP PUT method, and separate request bodies for "up" and "down" events are now implemented and deployed. @Grayda, feel free to test these changes out with Cachet!

kerem commented

2026-02-25 23:41:30 +03:00

Author

Owner

@Grayda commented on GitHub (Jun 3, 2019):

Thanks for that. I've re-created my webhooks to use the new options and I'll report back if anything goes wrong, but I don't foresee any dramas.

Thanks for being so prompt with the change :)

@Grayda commented on GitHub (Jun 3, 2019): Thanks for that. I've re-created my webhooks to use the new options and I'll report back if anything goes wrong, but I don't foresee any dramas. Thanks for being so prompt with the change :)