Alerts

Introduction

Table of contents
  1. Alert notification channels
  2. Alert settings
    1. Kind
    2. Monitors
    3. Schedule
    4. Other options

Alerts enable receiving critical status updates about different components of your infrastructure on various channels.

Alert notification channels

For now, you can select to notify the relevant person or the team via;

  • e-mail,
  • PagerDuty,
  • Slack,
  • webhook,
  • SMS (text message).
  • phone call,
If there is a third-party tool or service that you want to use for getting alerts from WebGazer, please let us know.

Alert settings

For each alert channel, there are different configuration options. But there are some common ones to. Here are the common configuration options for all alerts:

Kind

The kind of the alert, a.k.a. channel. The available options are, again:

  • E-mail
  • PagerDuty
  • Slack
  • Webhook
  • SMS
  • Phone call

Monitors

You can select different monitors for each alert. For example, you can create;

  • an alert to notify the backend team when an API checking HTTP monitor is down,
  • another alert to notify the platform team when the heartbeat monitor for the daily database backup fails,
  • and another one to inform the engineering director if any of the monitors stay down for 2 hours.

Schedule

Each alert has a scheduling configuration. You can set the alarm to run when a downtime or underperformance occurs or gets resolved. Or, as an escalation policy, you can set it to run only if a downtime or an underperformance lasts for a certain time.

Available options for scheduling configuration are:

  • trigger when a downtime occurs (immediately or if the downtime lasts for x minutes)
  • trigger when a downtime is resolved
  • trigger when an underperformance occurs (immediately or if the underperformance lasts for x minutes)
  • trigger when an underperformance is resolved

Other options

For channel-specific options, please see their individual articles: