Runtime Alerts

Runtime Alerts feature enables the monitoring of API behavior.

You can configure alerts to trigger notifications (via email, Slack, Microsoft Teams, Webhook, and/or WhatsApp) based on the events you specify.

Take a look at the examples below to explore the benefits of this feature.

Scenario Examples

target

Swift problem identification:
Now, the Site Reliability Engineering (SRE) team receives WhatsApp messages promptly when an issue arises, allowing for swift action. I’ve configured runtime alerts based on 500 status code returns and specified the exact message to be sent for each scenario, indicating possible solutions for expedited resolution. Additionally, POST requests are dispatched to the system responsible for generating reports for managerial analysis and planning.

Supporting business decisions:
My reconfiguration strategy encompassed a testing period. I introduced several new APIs to gauge their market reception. I set up runtime alerts to monitor the volume of calls made to these APIs. By understanding the adoption rates of each during the testing phase, I obtained insights to guide the optimal direction for my sales expansion project.

sign with multiple directions

In these and various other scenarios, alerts operate based on action policies. Each policy defines a specific scenario (event) along with the rules for triggering the alert.

Configuring Runtime Alerts

Configure policies to monitor API behavior and receive alerts when specific events occur.

Previous versions of Flexible Actions required creating an alert for each API. Now, with the concept of policies, the process has become much simpler: you create a Runtime Alert policy and select the APIs you want to associate with it.

Follow this link to understand how monitoring policies work.

Click the links below for information on:

Step-by-step

Creating a new policy;
Editing policies;
Deleting policies.

Detailed description

Policy list;
- Search;
- Policy details;

Detailed description

Policy list

example of policy list

The policy list displays information and action options. The columns available are:

CLASS: the policy classification, indicating its level of criticality:
- neutral,
- success,
- attention,
- critical.
NAME, the policy name.

The policy name must be unique.
TYPE: the category of parameters to be monitored, which can be:
- Total Calls,
- Availability,
- Latency, and
- HTTP Response Status.
ACTIONS: icons representing the notification channels:
- Email,
- Slack,
- Teams,
- Webhook,
- WhatsApp.
LAST UPDATE: date and time of the last configuration update.
ENABLED: button to enable or disable notifications for the policy.
OPTIONS:
- : opens the page with more details about the policy:
  - Event parameters that trigger the alert,
  - Monitored items (API name; number of environments, resources, and operations; total number of monitored items),
  - Notification channels, including recipients, configured message, and, depending on the channel, a button to send a test message.
- : initiates the steps to edit the policy,
- : deletes the policy.

Search

Find a policy using the search tool at the top of the screen.

You can filter policies by the following fields. To see all fields, click on button with three horizontal lines forming a triangle pointing downwards .

You requested it, and we’ve implemented it: now you can search by API name and policy name.

API Name: start typing the API name or click on the field to select from a list.
Classification: click and choose a level of criticality (Neutral, Success, Warning, or Critical).
Tags: start typing or select a tag (optional label added to policies during creation or editing to categorize them).
Status: select a state (Enabled or Disabled).
Policy name: enter the policy name.
Notification Type: select a notification type (Total Calls, Availability, Latency, or HTTP Response Status);
Action: select the notification channel (Email, Slack, Microsoft Teams, Webhook, or WhatsApp);

Policy details

Click on in the Runtime alert policy list to see details about the policy — that is, the information registered when creating a new policy.

The screen displays:

Policy name,
Monitored event details,
Monitored Items,
Notification channels (Actions), including recipients, configured message and, depending on the channel, a button to send a test message.

Editing policies

To edit the basic information of an alert (i.e., the monitoring conditions that will trigger a notification), follow these steps:

In the Runtime alert policy list, click on the edit icon in the OPTIONS column of the policy you want to edit.
Make the desired changes.
The steps are the same as those outlined in creating new policies.
Note that the notification type (Total Calls, Availability, Latency, or HTTP Response Status) cannot be changed.

If you need to change the notification type, you can delete the policy and create a new one with the desired type.
In step 4 REVIEW, review the changes, and click on SAVE to finalize.

You must click on SAVE for the changes to take effect.

The changes will only take effect from the next alert trigger.
When you edit the tags of an alert, the new tags can be immediately used for searches on the Runtime Alerts screen. However, in searches on the Triggered Alerts screen, the tags that were active when the alert was triggered will still be considered. For example, if you just added a new tag, it will only return search results in Triggered Alerts the next time the edited alert is triggered.

Deleting policies

Follow the steps below to delete an alert:

In the Runtime alert policy list, click on the delete icon in the OPTIONS column of the policy you want to delete.
Confirm the deletion by clicking on DELETE in the confirmation window.

If you only want to temporarily disable notifications for an alert instead of removing the policy, you can use the enable/disable buttons in the ENABLED column on the Runtime Alerts page.

Thanks for your feedback!

EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]