The reduced number of alerts is unrelated to concerns about delivery timely alerts. As I mentioned before, it is due entirely to us not having adequate data coverage in that portion of the world so we do not ever receive any sort of confirmation that the flight has actually arrived from any of our current data providers. Because of this, we are not willing to confidently send an arrival alert for such flights.
Data for flight events come to us from a variety of providers, which may be transmitted by ground radar, ADS-B, satellite, airport controllers, airline operators, or other. Each of these methods have differing amounts of delays that may be from just seconds delayed to 5 or more minutes delayed. When you use pushed alerts, we attempt to deliver the information as soon as we receive it. When you poll an API to request the updated status, you receive whatever data we have at that moment. We do not have the ability to predict when the precise time to poll an API again since the delay between data sources varies greatly.
A reasonable technique to poll the API status of a flight is to adjust the delay between your retry attempts depending on how close the flight is to arriving. You can use the estimatedarrivaltime field to decide how close it is to the current time. For example, when the estimatedarrivaltime is more than 15 minutes in the future only poll every 10 minutes; but when the estimatedarrivaltime is less 15 minutes in the future and less than 15 minutes in the past, poll every 2 minutes.