We have changed the way APIs are automatically detected by Bearer so that they are now separated by subdomains. This will allow for domains with many different APIs (Amazon Webservices, Microsoft, …) to be monitored independently. The API’s name is derived from the Fully Qualified Domain Name (FQDN).

To make it easier for our users, we automatically associate a service tag for all APIs in the same root domain.

Bearer’s Python agent is available today in Beta and includes all the passive features of our Node.js & Ruby agents, which include monitoring, anomaly detection, and logging. Don’t worry remediations will come in a future release.

To start using the Python agent, create a new application, and configure it with its App key!

You can also check out our full Python agent’s documentation here.

With this release, we are delivering a major change to Bearer. Our incidents feature has been overhauled and renamed “Anomaly Detection”. It allows for easier use of our rule system to identify what’s wrong in your app’s integrations. Of course, you can still be notified when an incident occurs, but now we can also do way more than that!

• Anomalies now have a Severity level attached. Edit the rules to customize it.
• We group them and count out their occurrences for better readability.
• Bearer-provided anomalies have a “paternity” system, allowing Bearer’s team to update their behavior as long as you are not customizing them. -In the future, we will add more new anomaly templates!

We have built the Anomaly feature around our Generic Rules system. We provide a set of starter rules that are enabled by default and already at work on your integrations!

Check out the feature's full documentation.

We have split the rules configuration by which feature they take advantage of. You can now find Anomaly rules in the Anomaly section, and remediation rules in the Remediation section.

This provides a better configuration flow for Anomaly & Remediation rules. They are now truly turn-key and can allow you to:

• Enable notifications in a click from rule configuration dashboards
• Set up notifications once for each application: you no longer need to reconfigure them for each rule.

• Choose any email or email-list configuration you like to receive our notifications.
• Continue to configure slack integration in a minute!
• Feature-flip your App with the webhook notification.

We also rebuilt the Custom Rule forms: they are now specialized for Anomalies and Remediations. This will come in handy when you start debugging complex issues.

We have released the very first piece of a feature we call “Fleet control”. It allows you to instantly see the version and location of all your deployed Bearer Agents.

This cool new feature is available in the “Agents” tab of your application’s settings.

Hostname detection is not available with agent version 3.0, but it will be available for everyone in our agent's version 3.1 release, coming for mid-may!

Next on our roadmap: receive notifications when agents are down in your environments.

Until now, Bearer offered 3 fixed environments per application: Production, Staging, and Development. We have released a brand new method of environment management that is scalable, configurable, and dynamic!

• There is now only one authentication key per Application
• Auto-detection of env_variables.
• Newly detected environments are created automatically.
• By default, every new environment is active. You can change this to “disabled” by default in the settings.
• Each environment can be activated or deactivated from the dashboard. It will disable all the agents that are associated with that environment.

To enjoy this new feature, you need to have at least Agent V3.0.0 and to update your agent's configuration. Legacy configuration and authentication keys are still valid. Migrate when you wish!

Check out our documentation to find the new settings:

• Node agent's documentation
• Ruby agent's documentation

You can find the new configuration in the Application’s General settings.

Last but not least, there is a cool color picker. Choose the color scheme you fancy!

Bearer agent version 3.1.0 is available, and new features are in order.

Node agent:

• New feature:
  • report agent’s hostname to Bearer for Fleet Control new feature

Check-out the Node Agent’s full documentation.

Ruby agent:

• New features:

  • Add support for timeout remediation for Ethon, Excon, HTTP, HTTPClient and Patron (only Net::HTTP was previously supported).
  • Report agent’s hostname to Bearer for Fleet Control new feature.

• Fixes:

  • Remediations: blocked requests are now reported.
  • The agent no longer fetches its configuration when it’s disabled.
  • Add requirement for base64 library.

Check-out the Ruby Agent’s full documentation.

A cool new feature has been implemented to Bearer’s dashboard! You can now use a log entry as the basis for a new custom rule, directly from the log. Rules are super handy to create incidents or remediations. Log to rule will make that even easier!

Starting with Bearer Agent V3.0, we are providing a cool new feature - remediations - to actively block, retry and timeout the API calls based on our Rules system. We now have a convenient Remediation page, where all remediations will be listed!

Try out remediations by activating one of them from our Rules panel.

• To increase data privacy and keep you in control, we have updated our API discovery flow. From now on, each discovery API will be in a “Newly Discovered” state. From the API list, you can easily turn them on and then enable the logging feature. No data will be sent to Bearer’s platform from the agents before you give us the “Go ahead”.

• You can now customize the Error settings and Logging Levels of each API we monitor. It is now possible to exclude a specific error code from the Error processing and Error metric calculation. This new feature’s purpose is to reduce the amount of false-positives errors and notifications you receive by fine-tuning your APIs.

• Define a log level setting, API by API. With this new feature, you can configure the agents to:
  • Not send the full payload to our platform, just collect the metrics
  • Send the full payload only when the call is an error + metrics
  • Send the full payload for each and every call (only available in Pro Plan)

• Last, but not least: you can now purge all data Bearer holds on a specific API in two clicks. When you confirm the deletion of the log, we will erase everything but the metrics!