Skip to main content
APIContext
Talk to salesStart free
Start HereGuidesConceptsCLIReferenceChangelog

Setting Alerts

Key Concepts​

An alert is a notification that lets you know that some particular event has occurred with one of the APIs that you are monitoring when the API was called. This might be that the call failed or the response was very slow.

You can use Conditions to set your own criteria for whether a response is flagged as a warning or an error. For instance, you might want to receive an alert if a required field in the the returned payload is empty.

You can also alert on a Pass, which is especially useful for negative testing in which yiu want to be alerted if a call passes.

We provide support for the following alert types:

  • Pass - a monitor has met the pass conditions (by default a HTTP 200)
  • Warning - a monitor has triggered a warning (by default a 4XX client-side result)
  • Error - a monitor has triggered an error (by default a 5XX server-side result)
  • SLA error or warning - the call or part of a workflow has exceeded its expected duration or some other specified Service Level Objective
  • Slow - the call is outside of an expected parameter

Managing Alerts by API Endpoint or Globally​

Alerts can be set on an API by API basis or globally for all your APIs.

To set an alert for a particular API, click on the Alerts & Webhooks tab of the monitor. Click on the +Add New Alert button to invoke the dialog.


The alert type can be via email or any of a number of Webhook services.

Alerts can be sent to the following platforms: Axiom, BigPanda, Datadog, Email*, Flowdock, HipChat, Hydrolix, Microsoft Teams, New Relic, OpenTelemetry, OpsGenie, PagerDuty, Slack, StatusPage, and VictorOps. Many platforms support OpenTelemetry, and we recommend OpenTelemetry as the default alerting mechanism.

*Please note that we do not recommend using email for alerting due to the potential for a high volume of alerts if your application experiences an interruption.

Next, choose your trigger alert criteria. This defines when you want the alert to be sent. There are four potential criteria, Pass, Slow, Warning, and Error (as described above). By default, a new alert is Enabled. If you disable the alert, you will not receive alerts even if an alerting criteria is met.

2056

Enter a name for the alert at the top of the section. Then, decide if you want the alert to trigger immediately when the conditions are met, or to delay the trigger until a specific number of failures have occurred. Often a single failure does not indicate a fundamental problem with the API, and we recommend entering a value of "1" here..

2054

Some integration types will require additional information, including Webhooks and OpenTelemetry integrations. Each service requires slightly different parameters, so review the configuration details and fill out the additional details from the target platform. For example, PagerDuty requires a valid Integration key and severity classifier. Each integration type has integration-specific parameters.

2074

Managing Alerts Globally​

To set alerts globally, click on the Alerts & Webhooks section of the side navigation and fill in the dialog. By default, you will create alerts for al the APIs in your current project.

2116

To disable alerts globally, navigate to Organization Settings, then select the Downtimes tab. Change the Allow toggle switch to OFF.

*Please note that this will disable ALL alerts for the organization until the toggle switch is returned to the ON position, and could cause you to miss critical operational alerts.

Learn how to create a monitor first: Monitor your first API.