Webhook alerts enable you to deliver status change notifications to an HTTP server. By webhook alerts you can:

  • receive events on your in-house HTTP service and automate something from there,
  • deliver notifications to any third-party tool or service that will handle the event in a different way (for example, IFTTT or Zapier).
If there is a third-party tool or service that you want to use for getting alerts from WebGazer, please let us know.


Please see here for common configuration options that are not specific to e-mail alerts.

webhook alerts

Webhook URL

Webhook URL is the URL that WebGazer will send an HTTP request when there is a status update for the selected gazers and pulses. Its protocol can be HTTP or HTTPS.

Anatomy of the webhook HTTP request

Webhook alerts deliver an HTTP POST request with a JSON payload.

The incoming request will have these headers:

Content-Type: application/json
User-Agent: WebGazer/1.0 (+https://www.webgazer.io)


The incoming request's body will have this data:

contentstringA human-readable description for the notification.
period.endedAtstring or nullRelevant period's end date and time in ISO-8601 format. Will be null for downtime or underperformance start notifications.
period.startedAtstringRelevant period's start date and time in ISO-8601 format.
period.statusstringRelevant period's status. It can be DOWN or UNDERPERFORMING for gazers. And only DOWN for pulses.
sourcestringSource of the notification. It can be GAZERS or PULSES.
sourceIduint64ID of the source gazer or pulse.


Here is an example request body:

  "content": "Phew: Gazer Website has recovered.",
  "period": {
    "endedAt": "2022-07-29T23:58:51.056434Z",
    "startedAt": "2022-07-29T23:53:27.277825Z",
    "status": "DOWN"
  "source": "GAZERS",
  "sourceId": 2
Webhook requests might also include description, period.ended_at, period.started_at and source_id keys. But they exist only for backward compatibility, and will be deleted soon. Please use their updated counterparts.