Getting Started

To allow our Instabug App Performance Monitoring to monitor your network requests, you will need to follow these steps.

GraphQL Support

Instabug officially supports capturing and aggregating GraphQL requests made using Apollo. In order to enable this, follow the network monitoring steps mentioned in the getting started section.

The below sample code snippet should be added after Instabug is initialized in order for the SDK to be able to track GraphQL requests made using Apollo.

import { ApolloClient, HttpLink, ApolloLink, InMemoryCache, from } from 'apollo-boost';
import { NetworkLogger } from 'instabug-reactnative';

//Setting up the handler
const IBGApolloLink = new ApolloLink(NetworkLogger.apolloLinkRequestHandler);

//Sample code
const httpLink = new HttpLink({ uri: 'https://example.com/api' });
const client = new ApolloClient({  cache: new InMemoryCache(),  link: from([IBGApolloLink, httpLink])});

📘

Using clients other than Apollo

If you're currently using a client other than Apollo, please feel free to reach out to our support team to verify support and add it to our backlog.

Payload Size

By default, Instabug captures the payload size of the request and response; this should help with determining if the payload size could be causing any issues with network delays. The payload size is the size of the payload itself, so it does not include the header's size.

Instabug automatically buckets payload sizes into different buckets based on the distribution of the data per network group, with a minimum sensitivity of 10 bytes per bucket.

URL Patterns

URL patterns are used to group the relevant network call occurrences and aggregate their numbers. Let's take the following examples:

• sample.com/list/3/item/1
• sample.com/list/3/item/2
• sample.com/profile/

It looks like 1 and 2 are the same request, but asking for different resources. While 3 is an entirely different one. Those three examples result in the following 2 URL patterns:

• sample.com/list/*/item/*
• sample.com/profile/

What Are the URL Pattern Components?

• Plain text: works with exact string matching
• *: matches with any URL part. * matches with only one part at a time. For example if you are mapping sample.com/part/variable1/variable2, your pattern should be sample.com/part/*/* and not sample.com/part/*

Does Instabug Detect Patterns Automatically?

Instabug automatically detects numbers and hexadecimal tokens in your URLs and replaces them with *.

Can You Create Custom Patterns?

If you are using more complex URLs where variable parts may contain plain text and not only numbers and hexadecimal, we recommend defining your custom patterns. Just click on the "Create URL pattern" button in your network list.

Here are a few examples:

Some notes to consider while creating your URL patterns:

• Custom URL patterns that you define have higher precedence than the auto-generated ones. If the same call matches with a custom and an auto pattern, it gets grouped with the custom.
• At any point, you can delete a pattern to prevent grouping new calls with it.
• URL patterns shouldn't overlap. Each incoming network call gets grouped with only one pattern. In case of conflict, it gets merged with the newest pattern.

📘

Creating or deleting patterns doesn’t affect your old data that has already been grouped. It only affects the upcoming network requests.

Network Calls Apdex

Instabug calculates an Apdex score for every network request (URL pattern) in your app. Apdex score ranges between 0 and 1. The higher the value, the closer you are to satisfying user experience:

• Apdex score ≥ 0.94 equates to Excellent performance.
• Apdex score ≥ 0.85 and < 0.94 equates to Good performance.
• Apdex score ≥ 0.7 and < 0.85 equates to Fair performance.
• Apdex score ≥ 0.5 and < 0.7 equates to Poor performance.
• Apdex score < 0.5 is considered Unacceptable.

How Is the Network Calls Apdex Calculated?

When a network call occurrence is collected, it is flagged based on a pre-defined target (T). A network call occurrence is considered:

• Satisfying: if its duration ≤ T
• Tolerable: if its duration < T and ≤ 4T
• Frustrating: if its duration > 4T or if it fails due to a server-side or client-side error.

Then based on the bucketing explained above, the Apdex is calculated:

• Total occurrences = Satisfying occurrences + Tolerable occurrences + Frustrating occurrences
• Apdex score = (Satisfying occurrences + 0.5 * Tolerable occurrences) / Total occurrences

How Can You Control a Specific Network Call's Target?

By default, it is set to 0.5 seconds; however, you can easily change this number from your dashboard by clicking on the action highlighted in the screenshots below.

📘

Please note that updating your response time target does not affect the already stored occurrences, only future occurrences will be flagged using the new target.

Disabling/Enabling Network Performance Monitoring

iOS

When APM is enabled in your account, network monitoring works out of the box. If needed, you can disable it on iOS by calling the following API after initializing the SDK.

// Enable
APM.setNetworkEnabledIOS(true)

// Disable
APM.setNetworkEnabledIOS(false)

🚧

Please note that disabling network monitoring in APM on iOS will disable Network Logs in Bug Reporting and Crash Reporting as well.

Android

When APM is enabled in your account, network monitoring works out of the box. If needed, you can disable it on Android via the relevant flag in Instabug's Gradle plugin as described here.

📘

Please note that, unlike iOS, disabling network monitoring in APM on Android will not disable Network Logs in Bug Reporting and Crash Reporting.