API Monitoring Frequency

How much is too much?

There are many schools of thought on the frequency you should monitor your APIs, but there’s no one specific answer to the question of what is the right API monitoring frequency. APImetrics offers a wide range of options from essentially every second through to a single call a day.

That said, there are some general guides we can give to help with this.

What is a meaningful sample size?

We’ve written at length about the perils of relying entirely on your existing log traffic – after all, it would be logical to think that all the traffic gives you what you need. The challenge is that it doesn’t always work that way for a number of reasons:

1. If the call isn’t reaching your servers you’ll have no logs to look at
2. Logs won’t tell you about issues with a partner or users cloud services
3. You might have too much data to sort meaningfully for a low frequency event – the flipside of this is you might not store the logs long enough because storing all the logs in a meaningful way gets very spendy quickly
4. Existing services might ignore failure chains – say a database that technically isn’t in your API stack is taken down – it’s not uncommon for an engineering team to set their systems to ignore client errors

With that in mind, we always recommend a series of sample calls from outside your stack to give you data that you can use as a control sample – after all, it’s what we do.

What are you trying to achieve?

The rule of the thumb with API monitoring frequency is that the higher is better, but only up to a certain point. Once a day is probably not enough because a lot can happen in a day and you can lose a lot of lot of money if something goes wrong and you don’t notice for the entire day.

Once a second is probably too fast because the signal will tend to be noisy and you can’t respond to things on a 1-second timescale (unless you are a high frequency trading bot). Every 5 minutes is typically a good frequency. This gives you good resolution of what has happened over a day and allows you to respond quickly in human timescale if something really has gone wrong.

Location Issues

Depending on your authentication protocol and load balancing system you might also need to consider monitoring frequencies by region too. If you are monitoring globally once a minute, so that over the course of a few hours you’ll have equal calls from different locations around the world, there could be significant gaps in coverage for regions. So if you have a regional load balancer go down you could miss it.

In that situation, or where a particular authentication routes to a specific location, you might want to schedule more frequent monitoring but distributed by location, i.e., a call every 5 minutes per region.

So what frequency should I pick?

It largely depends on your use patterns and what you want the monitoring to achieve but for most API based applications we usually believe 5-10 times an hour per region you’re interested in will give you enough warning to fix something that could have negative impacts on users before they start to notice.

For security monitoring, where you’re more interested in negative issues, such as accessing a forbidden resource or verifying that Tokens refresh as expected you might only do that a couple of times an hour just to be sure.

Pulling API Monitoring Frequency Together

You don’t need a massively high API monitoring frequency to generate useful data and give you insights into how things are working where your users are. But you should focus on samples that give you meaningful performance data and the alerting you need to be responsive to outages before your users notice.

APIContext has a world beating scheduling engine designed to help you as you can learn in this helpful tutorial.