6 ways Moesif API alerts can help your engineering, customer success, and sales teams
The ability to monitor your APIs is an important functionality for any business that is driven by APIs. Beyond API monitoring and observability is the ability to actively create alerts for specific conditions. Moesif is a fantastic platform to utilize alerts with. With our platform, all of your API and user data can be compiled into a single place. it’s a great way to easily configure a wide variety of useful alerts for your REST, GraphQL, and other APIs.
With Moesif, when an alert is fired, it can be delivered to many different channels including email, SMS, Slack, PagerDuty, or even a custom Webhook. By having many channels available, users can be sure that the right alert notification is being delivered to the right channel or multiple channels. This flexibility is a key factor in how Moesif enables you to customize for your business.
Not all alerts are equal though. In Moesif, we have two types of alert rules that can be configured: static and dynamic. Knowing the difference between the two and where to use them can help to build a robust alerting strategy.
Static alerts are quite simple. There is some metric that you’d like to track with a static threshold. For instance, you may want to create an alert that fires when a client receives a certain number of 401 - Unauthorized responses from an API. Your filter may look something along the lines of:
- Alert if more than 20 HTTP ‘401 - Unauthorized’ status codes are returned in a REST API response within 15 minutes
For dynamic alerts, the criteria are usually outside of the capabilities of a static alert. Dynamic alerts leverage Moesif’s anomaly detection. This mechanism compares against the trend line from historical data and alerts when the metric looks abnormal. The sensitivity is configurable so that the alerts can be customized based on exactly how much variation is acceptable before an alert occurs. An example of a dynamic alert filter might be something along the lines of:
- Alert if a user’s API usage is abnormally decreasing over the last week
Both types of alerts can be a great addition to your support and alerting strategy. When used in unison, they can help to improve multiple areas of the organization and keep customers happy. Let’s look at a few specific scenarios where implementing alerts could help you improve!
To track errors occurring in your APIs
The ability to track and notify teams about errors occurring in their APIs is likely a top use case for alerts. Errors are low-hanging fruit in terms of events that could quickly stall your business and bog down your support team.
The easiest way to do this would be through a static alert. An alert notification may be sent when a known endpoint is returning an HTTP 404 Not Found status code more than 10 times in 5 minutes. This may be due to some code configuration issues in the latest API code release or another error that the engineering team will want to know about right away.
Dynamic API alerts may also be set up to detect when there is an abnormal amount of errors happening in an API compared to historical data.
Having your team be alerted in real-time that an unwanted event has occurred is important. Knowing right away means that teams can diagnose, warn customers about any implications, and get ahead of any negative effects. This is especially important as support SLA times continue to decrease and become an important part of a user’s choice to adopt a platform. With Moesif, you can even use the platform to debug and recreate the issue more easily. Know the moment the event happens and resolve it more quickly and easily.
To track potential security issues or API abuse
Using alerts to warn the support and security teams about potential security issues can easily be done. This would help to cover your bases for securing against attacks and intentional misuse. In the form of a static alert, you may send an alert if a blocked user sends a request to a specific endpoint or still logs in somehow. With a dynamic alert, you may inform your support teams of an unexpectedly large spike in API traffic that may resemble a denial of service attack.
This is a great line of additional defense in the security battle. The first line of defense would of course be to block these events from happening in the first place. This could be done by ensuring you have proper API security mechanisms in place. This could include only allowing fully authenticated and authorized users to access an API or enforcing proper rate-limiting and quotas to each API call. An API gateway will have all the functionalities to create this first-line defense.
If that defense is breached or is for some reason bypassed, Moesif’s alerts are a great way to ensure that your team is still informed of any improper or damaging use of your APIs. Of course, digging deeper may also bring out other great ways to use Moesif to enhance your API security and limit abuse.
To reach out to new users who are stuck or struggling
Finding issues and being proactive to help struggling users is hard. When a new user comes on board, a metric we love to track is TTFHW, or “Time to First Hello World”. This metric usually follows users from when they first register until they have their first successful “Hello World” moment. For most technical products this journey includes registration, initial configuration, up until their first successful API call.
This metric is extremely important since it heavily defines how easy our product is to use. The easier the product is to use, the higher the likelihood that the user will continue to use the product. The first initial experience with the product is crucial.
As we know, this journey takes time to perfect and it will always have snags. Very few companies have perfected their user journey, but good companies strive to come close. What if we could be alerted when a new user is stuck? Then our customer success team could be alert and reach out to that user. With Moesif, we can do exactly this. A great example may be if a user is receiving an HTTP 400 Bad Request response code when sending their API requests. This could obviously be very frustrating and would be a major deterrent for the user.
As an example, we could set up a static alert to fire when users appear to be having difficulty. This alert may fire when any new users experience more than 5 HTTP 400’s and their TTFHW > 5 minutes. We could then have this alert go to the customer success team and do a personalized reach out to them to get them unblocked. This alleviates the need for the customer success team to actively monitor these details. It also means that the customer success team can be more effective in reaching out to users before they give up and possibly never return to use the system or application again.
From a dynamic alert perspective, we could set up an alert to fire if new users TTFHW becomes abnormally long compared to our historical data. This may help to inform product and engineering teams that the latest onboarding tweaks are impacting users.
To improve the user experience with new and updated features
What if we could be alerted when a user is having difficulty using a new feature in our product? This could allow us to do an outreach campaign to ask what the difficulties were. It could also allow us to intervene with the user to de-escalate their frustration if they face an error, help them to use the feature properly, and possibly refine the UI or docs to make usage more streamlined. We may identify API calls that are part of a particular user flow and either put a static alert around them if we know what an acceptable time threshold is to complete it. We may instead create a dynamic alert that checks against historical data to ensure the user flow has not become more difficult to use with our latest release.
The ability for customer success, product, and engineering teams to be alerted when features go awry can be a lifesaver. Instead of waiting for feedback to come in through channels or seeing users churn out due to difficulty, we can be alerted to these metrics when they go in the wrong direction.
To inform customer success teams about decreased usage for proactive outreach
If a user’s usage is decreasing there could be many reasons. They could be scaling down operations, got stuck with a roadblock on the platform, or may have made some issue in their configuration that they are unaware of. Regardless of the cause, it should be of concern to the customer success team.
By using dynamic alerts, the customer success team could be notified when key customers, or all customers depending on how you set up the alert rule, have decreased usage on the platform. The dynamic alert could look for anomalies or trends that would display a significant usage decrease. The customer success team could do an investigation, and even proactively reach out to the users to see if they can help.
This type of proactive approach is a great way for the customer success team to show they are invested in making the user’s business a priority. Proactive outreach can help with retention, churn, and customer satisfaction. Some of this can be automated, of course, but having the customer success team aware of issues is still an asset.
To inform sales teams about increased usage for upsell opportunities
Whether your mid-contract or coming up to a user’s renewal date, increased usage can lead to increased revenue. Instead of waiting for the sales team to be reactive, alerts can allow your sales teams to be proactive in bringing forth upgrade opportunities.
You could do this in quite a few ways using static or dynamic alerts in Moesif. With a Static alert, you could alert the sales team when any new user has more than a specific quota of API calls in a specific timeframe. This could signal to the sales team that the new users could be a very big account. Instead of browsing through usage data to figure out who to reach out to, let the alerts do the work.
You could also use a static alert that responds to a “percent change” metric. An example would be to send an alert when a customer has a greater than 20% increase within the last 7 days. This approach would give sales teams a heads up that a specific company is scaling quickly. This can help sales teams to reach out early for upgrades or help to inform upcoming sales calls.
Both of the above use cases can also help the sales team avoid “sticker shock” with customers, especially new ones. “Sticker shock”, in this context, is when the customer gets hit with a surprise bill due to usage. Sometimes this can lead to a loss of trust with the customer. The customer may then look for more platforms or apps that will cost less. In this scenario, possibly upgrading the customer to the next tier or package would help. Tracking metrics like quotas and growth percentage can give an advantage for customer retention and battle against “sticker shock”.
Once a history has been established, you could also set up dynamic alert rules. The alert would look at historical data and see if the user’s APIs are experiencing continuous usage growth. If so, the sales team could build a proposal ahead of time and bring the upsell opportunity to the user before they even know they need it.
Some products will also have related features. Where if “X” feature is used, then “Y” feature would be beneficial. Alerts could be set up to detect when a specific API is used. This would let the sales team craft their messaging and outreach campaigns to cater to this information and propose a package that involves the other complementary feature.
This also shows that your company is invested in a customer’s business and helping them to scale. These types of alerts can help the sales team to nurture new and existing customers proactively.
Setting up your first alerts
Now that you know about all the benefits, it’s time to try it out! We have some great guides available to show you how to create your first static or dynamic alert. To dig further, you may also want to check out our extensive docs. It’s as simple as creating your alert definition, configuring your channels, and activating the alert. The Moesif dashboard makes configuring alerts seamless and easy. Moesif even has some common alerts set up by default in the alerts dashboard. If you don’t have a Moesif account, sign up today! Once logged in you’ll be able to create custom alerts to augment your API monitoring game. Whether you’re using a REST API or a GraphQL API, Moesif alerts are a great way to increase awareness across all departments.
Related Articles
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.
API Analytics and Monitoring
How Moesif API Observability Compares to Treblle
Learn how Moesif’s API observability platform compares to Treblle.
