Over a million developers have joined DZone.

How to Get Started with Mobile App Monitoring

DZone 's Guide to

How to Get Started with Mobile App Monitoring

Monitoring the performance of your mobile application is key to it's overall success. Learn how to use some helpful tools to do just that.

· Mobile Zone ·
Free Resource

Every mobile app developer should consider how end-users of their app experience their app or service. For this purpose, Bitbar has developed its user experience monitoring that allows app developer organizations to monitor, inspect, and get instantly alarmed if something happens with the user experience flow from the end-user’s point of view. To get the best possible tools and method available for developers, we’ve launched a localized monitoring service that uses real Android and iOS devices, with real networks and variety of different geographical locations.

This blog provides all the steps you need to take in order to get started with synthetic mobile monitoring at any location around the world.

The most critical metrics for mobile monitoring are the user experience, performance, up-time, and how transactions work from various locations. Bitbar Monitoring provides the most cutting-edge and unique solution for companies to monitor their apps, mobile games, websites, and back-end integrations around the world using proactive synthetic mobile monitoring to ensure user experience requirements are meet.

Step 1: Create an Account for The Service (or Use Your Existing Bitbar Account)

To get started, create yourself an account at Bitbar. If you have an account with Bitbar Testing, you can use the very same account for Bitbar Monitoring and no additional account creation is required. The account can be created in both locations:


After you have created an account, log in to the service. If you are looking for a personal demonstration of how Bitbar Monitoring works, what it will deliver for you, and how to use it with all its awesome features, you can also schedule a mobile monitoring presentation with our experts.

Step 2: Select Which Type of Monitoring Check to Run

Whether you are in need of relevant and accurate data about your mobile app on any physical locations, the Bitbar User Experience Monitoring provides you versatile options to implement ‘Checks’ for your app, game, website, or back-end integration. The ‘Check’ is an execution of a defined Appium test automation script, single HTTP GET command or a page load for your website against any web end-point. Simply, click ‘Create Check’ on the main dashboard of Bitbar Monitoring and the following selection window will be open:


The HTTP GET is a basic API check to verify that some endpoint is responding and returns an expected return value. With the HTTP GET, it is possible to add a regular expression check for additional validation of the received response message. Read more about HTTP GET with Bitbar Monitoring.

Page Load

The user-provided web address is opened using a Safari (iOS) or Chrome (Android) web browser. Until the page is loaded, all network communication is tracked and reported into the check run. With a Page Load functionality, it is possible to create an additional regular expression check on the main source file that is downloaded. If additional content checks are required, then the use of Appium check is highly recommended. Read more about Page Load for Mobile Website.

Appium Test Automation

Functional and web content checks can be created using Java and Appium. An Appium check can be developed remotely on the developer’s machine and then uploaded with the application under testing to Bitbar Monitoring for monitoring checks. Appium supports the testing of native, hybrid, and web applications on iOS and Android platforms, and provides a versatile use case for various types of mobile monitoring checks. Read more about Using Appium for Mobile Monitoring.


Step 3: Select the Right Parameters, Location, and Preferences to Your Monitoring Check

After you’ve selected which monitoring check is used in the following parameters, physical locations to be used for a monitoring check, the frequency of checks and conditions for an alarm can be configured.

Physical, Real Location for a Monitoring Check

The first thing to do is to select which physical locations you want your monitoring check to include. This includes real, physical networks in those locations and typically there are plenty of different networks in the same cities/countries that are available. Select the ones where you prefer your monitoring check to happen by just marking those locations as 'on' – and click ‘Next’:

Frequency for a Monitoring Check

The interval for a monitoring check can be configured next. We provided some typically used frequencies (every 15 minutes, 30 minutes, hour, 2 hours, 3 hours, 4 hours, 6 hours, 8 hours, and daily) as default, but this can be further customized if you need monitoring checks to happen more frequently. Simply select the preferred frequency and click ‘Next’:

Actions for an Alarm After Incidents

Bitbar Monitoring provides very flexible and versatile options to alarm the right people or instance when errors, failures or something unexpected happens with your mobile products. For example, you can define email, Slack, PagerDuty, or simply wait (and check again later) when something unexpected happens. The configuration view for Actions looks like this:

Actions are rules attached to a monitoring check that act based on failures. When creating a new check against some service, regardless of the check type, in the case of failure the user should decide what actions need to be taken. The following options are used for alerting the user about failed checks:

  • EMAIL: Sending an email is useful for reporting when something happened, but typically is not reacted to very fast. Mailing groups are great to get a wider recipient audience for the failing check.
  • WAIT: Sometimes it is alright for a check to fail once, or twice before it is necessary to start further investigation. The wait time is of the same duration as the check interval. A wait means that it is not necessary to jump on the current failure, but let’s wait for the following check's results.
  • SLACK: Failures that require immediate attention are good to be sent as messages to a shared Slack channel. Before it is possible to send messages to Slack, the channel, and permissions to send to the channel, need to be provided in the user’s settings. Slack rights and channel information are configured under the main menu’s Settings link. When clicking on the Slack button, it is necessary to log into Slack and give Bitbar Monitoring the right to post to the desired channel.
  • PAGERDUTY: PagerDuty is an information gathering platform where various systems may send their notifications. PagerDuty provides means to handle the incoming events and take appropriate actions to resolve them. Before it is possible to send anything to PagerDuty it is necessary to set up the connection between Bitbar Monitoring service and PagerDuty. This can be done under the user settings.

When all your parameters are properly configured, click CREATE on the bottom of view and a monitoring check will be created.

Step 4: Reviewing the Results of Monitoring Checks

Bitbar Monitoring provides results quickly, with rich details. When you’ve started a monitoring check for any of the mentioned products, you can review results under your check dashboard, for example:

Click any of your monitoring checks and you’ll get rich details of what is going on, the performance of your product (app, game, or website) and what the general availability of the service has been like. All this data is presented as graphical and textual details:

To inspect a specific monitoring check, simply click filter on the bottom (OK, Timeout, Fail, Error, Skip) and you’ll get the full view of all your monitoring checks at Bitbar Monitoring:

If you're looking for more detailed information about Bitbar Monitoring for mobile apps, take a look at our product documentation and samples at Github.

mobile ,app monitoring ,application development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}