Client-Side Monitoring Is a Must for Mobile Apps
The vast majority of mobile applications rely on making network requests to deliver a successful user experience. However, many engineering teams do not have client-side network monitoring. Instead, they rely exclusively on backend monitoring to understand where network failures are happening across their systems.
This gives you an incomplete, and possibly incorrect, view of what your mobile users are experiencing. Read on to learn why client-side network monitoring is so important and what you are missing if your only visibility into network performance is from a backend perspective.
Not All Requests Make It to Your Backend Servers
Your backend can only measure the behavior of network requests that actually reach your servers. Below are a few reasons why requests would fail to make it there.
No Internet Connection
There are scenarios where it is not obvious to mobile users that they don’t have a connection. For example, a user can be connected to a WiFi access point, but the upstream connection from the access point is down or has intermittent connectivity.
Interrupted Connection
Even if you initially make a successful connection to a backend server, there’s no guarantee that the request will complete successfully. This is more common with mobile apps than queries made from PCs since mobile connection quality is more dynamic and prone to interruptions or degradations. While backend monitoring may catch this behavior, it’s not an issue that you’d normally prioritize. And even if you did, the server that lost the connection will not have any context about what caused the interruption. On the client side, you can see if anything happened, for example, an unsuccessful switch from WiFI to WAN, and if other network connections made around the same time also failed.
DNS Resolution Failures
If the app can’t resolve a hostname, it won’t be able to make a connection to your backend servers. And, while less common, ISPs can ignore caching rules for DNS entries and cache data for days or even weeks. When you make changes to your DNS settings, you expect downstream consumers of your DNS entries to respect the time to live (TTL) you set, but there is nothing to prevent them from ignoring the TTL. This means devices running your mobile app would resolve hostnames to IP addresses that may no longer be in use.
Requests failing with UnknownHostException after DNS misconfiguration.
Not All Requests Are Accepted by Your Backend Servers
Even if your application can connect to your backend servers, the servers may reject the connection for a variety of reasons.
Failed SSL Handshakes
This is especially common for older Android devices that have expired root certificates with no viable fallback. Another common failure case is when the user sets the clock on their device so far into the future that your SSL certificate no longer appears valid (gotta get those extra lives in games that hand them out after a certain delay!). Perhaps data collection on your servers provides some visibility into this, but this data can often be harder to capture from commonly used proxy servers such as NGINX. Even if you can detect it, you will not have much information about who it happened to since the secure connection could not be established.
This type of error happens frequently for ad-related domains. On one recent day that we analyzed, seven major advertising companies had SSL failures for over 1% of the network requests made to their domains, spread over hundreds of applications.
Ad-related and other third-party service SSL failure rates outpace those for first-party requests in a typical application.
Servers Overwhelmed by Request Volume
Often when backend issues happen and you want to understand the effect on your users, you operate without a full set of information. This is because the overloaded servers are also the ones that are supposed to collect the diagnostic information.
Not All Requests Are for Your Backend Servers
With backend observability tools, you have some level of visibility into network requests sent to your servers, but you have no visibility into requests sent to third-party services. Many important parts of mobile applications require access to network services that you do not directly control, such as:
- Payment providers.
- Ad providers.
- Map services.
- Content delivery networks (CDNs).
- Infrastructure-as-a-Service (IaaS) providers.
- Single sign-on (SSO) providers.
You must monitor network behavior from the client side to get insight into how the SDKs that provide these services are performing. Error rates, both for connection errors and HTTP errors, are often higher for the domains these services use than for first-party domains. In some cases, the error rates are at or near 100% due to configuration errors that are not easy to detect during testing.