Identify API Incidents with Built-in Anomaly Rules
One of Bearer's super powers is anomaly detection. Anomalies are unexpected issues that happen when making an API call. These could be high error rates, unexpected response codes, latency spikes, and more. By monitoring APIs with anomaly detection, we can identify problems with an API or within your application. Anomaly detection makes debugging easier and can help you identify API performance issues that affect your end users.
All accounts come with built-in anomaly rules to cover the most common anomalies. These let you take immediate advantage of Bearer without the need to configure anything. Every anomaly they detect is saved in the anomalies log collection for you to review, and you can even set up notifications for specific rules. You can start taking advantage of anomaly detection right away by creating a Bearer account or signing in.
Below are a few of our favorite built-in rules that showcase the power that comes with detecting API failures.
Rate Limiting Error
One of the most-searched-for problems related to APIs is the 429: Too Many Requests error. This HTTP status code occurs when your application reaches an API's rate limit. Rate limits can be monthly, daily, based on a sliding time-window, or surge-based to avoid large bursts of requests.
The built-in Rate Limit Error anomaly watches for this specific status code so you can keep track of occurrences and receive notifications when they happen. You can also create a custom remediation to retry rate-limited requests after a set amount of time. This is a great way to resolve the time-window and burst-limit types of rate limits.
Once you build an integration, write the tests, and have it running for a while, it can be easy to forget about it. When an API provider plans to deprecate features, or an entire API, they should notify you. Sometimes an email goes out, but other times the warnings come as headers on the API response.
Our Deprecation Warning anomaly rule watches for the most common deprecation warnings so you don't have to. It checks for the common deprecation headers like
X-API-Warn, but also more unique ones like
By configuring the notifications for this rule, you can know immediately whenever the rule detects a deprecation. The sooner you find out, the more time you have to make the necessary code changes to ensure your integration keeps working.
API is Down
Status pages are notoriously unreliable. Many providers update their status pages manually. By detecting for a consistent stream of failed requests over a set timeframe, the downtime anomaly rule can alert you when an API outage occurs, even if the provider hasn't published the outage.
It works by watching for a 100% error rate over a 5 minute sliding time window. If you need a shorter or longer window, you can build a custom rule that mirrors the functionality of this rule.
Have you experienced a sudden spike in API usage? It could be a bug in your codebase, or a rogue user performing a repeated action that you weren't expecting. Either way, large bursts of API consumption can be costly at best, and cause your application to be rate limited at worst.
The consumption surge anomaly rule looks at normal usage over a sliding 15 minute window and watches for a percentage increase. This defaults at 300%, but you can modify it to better suit your needs. When it sees a sudden jump in usage, you'll be notified.
Error Rate Surge
Similar to the approach used in the consumption surge rule, the error rate surge rule watches for sudden spikes in API errors. It is common to see API errors. These can be the result of poor data, a brief network problem, or even the way that providers return data. What you want to look for is a sudden spike in the error rate. This indicates there is a deeper problem, either with the API provider you're using or with the way you are integrating with the API.
Many API clients and HTTP libraries will understand a 301 or 302 response, and follow it to the correct resource. You can generally live with this redirect, but it can also be a sign that you should update your calls to use the new resource location. Not only will this ensure you don't run into any deprecation problems later, but it also improves the speed of the request.
The built-in redirection warning works the same way as other anomalies. Once detected, Bearer will notify you when any API calls encounter a redirection.
Beyond the default anomaly rules
These rules may be our favorites, but Bearer ships with a growing collection of built-in rules for the most common anomalies. You can start configuring them from the anomalies screen in the Bearer dashboard.
For any edge cases that are not covered by the built-in rules, you can create your own custom rules with some of our plans. If you need something more hands on than detection and notification, you can use Automated Remediations to recover from API errors automatically.