Skip to main content


Best Practices for Monitoring APIs

As discussed in our Why Should You Monitor an API  blog, monitoring APIs is not only recommended but in many cases essential to business performance.

So, you’ve taken the plunge, and you have an app that requires an API. Your job now is to determine how to monitor that API to ensure that it is providing the best data at regular, agreed-upon intervals. What is the best way to assess the value of the API you choose?

Do Your Due Diligance

Avoid problems down the road by putting in the extra effort to research your API monitor at the outset. Determine whether the monitor has a public status page for services provided to learn about the transparency that the company has when it comes to business data. This should shed light on their availability as well as the types of problems that they’ve had in the past.

Require an SLA

Make sure that the company offers an SLA (Service Level Agreement) in which they outline and guarantee specifics on service indicators including availability, latency, and scheduled maintenance times. If you are paying for an API monitor, the provider should offer and stand by this SLA as an indicator of legitimacy and quality assurance. Awareness of downtime and latency may prove to be crucial in creating your own resilient code for times that API does not return quality data. To find out about the previous outages suffered by the provider, check Google and Twitter, and pay special attention to the responses by the provider to the comments and complaints by customers affected by the outages.

Does the company provide incident reports? A reputable company should provide incident reports to notify customers about what happened to cause the issue, how it can be worked around, and how/when the provider will fix the problem. Ask the provider if they have a 99.9% or a 99.999% annual availability (remember to keep in mind that the scheduled downtimes are not included, but will impact your app). Finding an API provider that you have confidence in will relieve stress as well as decrease the continued verification required that we’ll discuss in the next section.

Best Practices for Monitoring an API

How To / What To Monitor

Measure an API from where you are calling it from. You likely require a quick connection from the server to your app, so testing near your application is important for the most realistic indicators of the quality of your API monitor.  Testing an API from multiple locations is a great way to ensure that the provider is high quality and standing by the 99.9% or 99.99% standards of availability that they claim. These additional tests are only worthwhile if you’re paying for the API, and it is valuable to your company.   By checking different locations, you can find the availability and uptime for the provider independently from its sales pitches.  If one connection fails for a location, you can fail to the next location to find the source of the problem and pinpoint it in real-time.  There is an important distinction between whether the API is down or the network is down between your app and the API; testing from a set of locations allows you to determine which it is.  These are the most important criteria to track:

  • Availability: Is the API reachable or not?
  • Responsiveness: When ordered, does the API provide quality data?
  • Latency: What is the speed of the response to a call to the API?

SLA will cover a certain level of performance, and if your provider doesn’t meet the standards that you agreed upon, let them know. Also, consider looking for a better provider.

Assume Failure

Write code in a way that allows for it to call to the API and not receive data.  At times, the API may fail, although it is unlikely that an API failure will occur during development for your app.  Remember to make your code resilient so that when it receives an error message or mangled data, it will continue to function. When writing code with lots of local calls, a wrapper that calls to an external API often goes without notice for the intricacies of reaching out to populate the app.  Lastly, consider the specifics for latency set forth by the SLA to write code that will wait appropriately to populate the data set from the API.




Learn more about Digital Experience Monitoring