Learn more about anomalies and how to use them to monitor your API integrations.

A core feature of Bearer is anomaly detection. Anomalies are events caused by an unexpected incident with an API call. Bearer comes with an assortment of built-in anomaly rules to detect the most common problems with APIs. As with all sections in the Operations section, you can change the current application and environment view by using the selector in the top left.

By default, these built-in rules will only display anomalies on the dashboard and in the anomalies log collection. You can enable notifications in the rule settings, which can be accessed through the ... (ellipsis) icon.

Built-in rules do not count toward the maximum active rule count defined in your current plan.

View All Anomalies

Selecting the View all anomalies link takes you to the all anomalies view. Here you can view all anomalies from the current retention period and filter them by specific anomaly rules, API, or time period.

Anomalies with available log information are indicated with the more information arrow. Clicking the anomaly entry will reveal further details about entry and provide any available details about the API call that triggered the anomaly rule. Here you can create a shared link to the log entry, and even create a new anomaly or remediation based on the details of this log entry.

Add a Custom Anomaly Rule

To add a custom anomaly rule, select the Add a Custom Rule button.

Custom anomaly rules require some general information about the rule, filtering options, and how you would like the rule to notify you when an anomaly occurs.


Each anomaly can have a name and a description. In addition, you can assign anomalies to apply to all APIs, or a specific API. Anomalies fall into two detection types:

  • Call by Call Filter Match: This detection type monitors all API calls and checks them against a set of filters that you define.

  • Sliding Time Window: This detection type allows you to define a trigger condition such as Error Rate, Consumption, or Average Latency. When the condition occurs within the time-window you define, the anomaly will trigger.

Finally, each anomaly can be enabled or disabled whenever you like. Depending on your current plan, you may be limited in the number of anomalies that can be active at a given time.

Call Filtering

Both detection types offer the ability to further narrow down the criteria required to trigger an anomaly. Call filters allow you to match against various aspects of an API call including:

  • HTTP Methods

  • Status Codes

  • Connection Errors

  • Paths

  • Request Parameters

  • Headers

Each rule can have a maximum of 5 filters, and you can require that all or any filters are met in order for the rule to trigger.

Notification Settings

When an anomaly occurs, it is automatically logged in the anomalies list, as well as the anomalies log collection. You can also choose to receive notifications for specific rules by configuring your preferred notification methods. Notifications can be configured in the Notifications section of the Settings screen. Currently, Bearer supports being notified by Email, Slack, or through a custom webhook.