Feature Request: Post to webhook on failed health check

[carterbryden]

This might be outside the scope of Caddy, but it would be fantastically useful if Caddy health checks could be configured to post to an arbitrary URL on failure (or maybe even success too).

Something like this in the JSON config for /apps/http/servers/routes/handle/reverse_proxy:

{
  "health_checks" : {
    //passive or active configs,
    "actions" : {
      "failure" : {
        "webhook_url": "your.apiurl.com/your-url"
      }
    }
  }
}

Ideally it would post some json to that webhook URL that would let the receiver identify the route, the datetime it failed, etc.

I think this could be really valuable for a lot of use cases (basically free uptime monitoring) and it feels like it would fit in well with a lot of other features that really make Caddy stand out in terms of practical convenience.

[francislavoie]

Not a bad idea, but I'm not sure that specific config example would be what we'd want to go for - I think it would be better to find a solution that's more generalizable instead of only supporting webhooks.

I think this might fit into the realm of "event handling", where the reverse_proxy handler could emit an event that could be handled by some event.handler.* module, all this configured under an event app maybe. There's demand for events already such as #2344, and having a way to handle various kinds of situations would be quite powerful.

Anyways, not quite the same, but you can use the reverse_proxy's handle_response functionality right now, to handle 502 statuses (i.e. none of the upstreams are usable; unfortunately not if it's just a single one) with a reverse_proxy to your "webhook" endpoint; you can set headers with the context info. https://caddyserver.com/docs/json/apps/http/servers/routes/handle/reverse_proxy/#handle_response

[carterbryden]

you can use the reverse_proxy's handle_response functionality

That sounds like it would cover my use case well enough actually, thanks for the tip.

As for event handling, I agree that would be a much better and more powerful means of accomplishing this idea and a number of others. The only reason I'd suggested something webhook specific was to try and keep the scope small with as much utility as possible. I'd much rather see an event handling system in the long run.

[mholt]

I also prefer the event handler module. That way any app can emit events and have it handled flexibily in a separate module dedicated to that.

[mholt]

Implemented in #4984