Dynatrace APM: why a mobile app "slows down" unnoticed
A typical picture: users complain about freezes and crashes, while the server side shows a flat graph — response time is normal, there are no errors, resources are not hitting the ceiling.
The gap is explained simply: server metrics only see the requests that made it to the server. Everything that happens before that — app startup, screen rendering, work with local storage, the carrier network — remains out of view. That is exactly where the bottleneck hides.
Dynatrace APM closes this blind spot: the agent is installed in the app itself and collects data from the user's device, not from the server. You can see which screen the user freezes on, how long a cold start takes, which calls to the server do not get through and why.
Failures on the device stop being anonymous — instead of "it doesn't work for someone," you get a specific app version, device model, OS version, and carrier.
From there, the picture forms into a cause-and-effect chain. If only one carrier is slow — the problem is in the network, not in the code. If the failure occurs on a specific model — it is a matter of compatibility or insufficient memory. If a slow call repeats for everyone — the bottleneck is in the app itself.
Mobile app monitoring in Dynatrace APM links the complaint, the technical cause, and the affected share of users, so fixes go to the place that actually affects the experience, not to the place that complains the loudest.
Below, we break down how this unfolds on a project: what exactly is collected from the device, how to separate network failures from code errors, and how to set up alerts so that we learn about degradation before users do.
What end-to-end monitoring delivers: impact in measurable terms
End-to-end tracing links a user action on the device to a specific request to the backend and records in the database.
Previously, this data lived in different systems: the mobile crash log separately, the server metrics separately, and they could only be correlated manually by time.
Now a single session unfolds into a complete chain of calls — from the tap to the backend response, with timing at each segment.
Response time stops being an averaged number. It becomes clear that the 90th percentile stays within the norm, while the tail grows due to a specific request to the authorization service.
This changes priorities: what gets optimized is not what slows down most often, but what determines the worst experience.
The share of failed sessions is calculated by users, not by requests. A session in which a person closed the app after three consecutive errors is counted in the statistics once — and that is fairer than a thousand retries from a single client.
The failure class is determined automatically: network, server error, crash on the device, or integration timeout. The engineer gets not "something broke," but a specific category tied to the app version, device model, and mobile carrier.
A separate value is release control. Comparing metrics before and after rollout shows whether the share of failed sessions increased on the new version, and a rollback is decided based on data, not on complaints to support.
Data Collection Methods: Comparing Instrumentation Approaches
The method of connecting monitoring determines what data you will see at all. Full instrumentation via an agent on the device provides distributed traces for every call, including internal methods, but requires rebuilding the application and accounting for privacy policies.
Network traffic interception (a proxy or VPN profile) does not touch the code, but loses context inside the process and does not see background tasks or work with the local cache.
Below are the real options that teams choose between at the start, and their limitations. They can be combined: the agent covers depth, interception provides a quick start without a release.
| Option | When it fits | Limitations |
|---|---|---|
| Agent on the device (full instrumentation) | Distributed traces, crash and UI freeze metrics, backend correlation are needed | Rebuild and release, increased build size, data privacy configuration |
| Manual metrics via SDK | Targeted control of key scenarios (payment, login, checkout) | Covers only instrumented paths, the rest is a blind spot |
| Traffic interception (proxy) | Quick network audit without changing the application, troubleshooting integration issues | No context inside the process, does not see background tasks or the local cache |
| Synthetic checks | Monitoring availability and response time of critical scenarios from the outside | Do not reflect real user behavior and devices |
| Logs and crash reports | Basic diagnostics of crashes and anomalies | No end-to-end correlation with requests, manual incident correlation |
In practice, most often the on-device agent is complemented by interception during the implementation phase: first the network picture is captured without a release, then deep traces are added. This way the team gets data immediately rather than waiting for the next build.
How implementation works: stages of engineering effort
We start implementation with a telemetry audit: we look at which events the application already sends, where context is lost between the user session and the server request, and which failures remain invisible.
Based on the results, we record the list of signals that need to be collected and the points where data for incident analysis is currently missing.
- Audit of current telemetry. We review existing logs, crash reports, and metrics, and note the gaps: network calls are not tracked, there is no binding to the build version, and the session identifier is lost on restart.
- Design of the collection scheme. We determine which events, metrics, and traces are captured from the client, what is aggregated on the service side, and how the mobile session is linked to the backend — a single identifier passes through all layers.
- Instrumentation of the application and services. We embed collection into key scenarios: launch, authorization, payment, and work with data. We separately mark user actions so that conversion drops can be read step by step, rather than as "somewhere in the application."
- Setting up dashboards and alerts. We build screens for real questions: the share of successful scenarios, response time of external services, and failure frequency by version. We set alert thresholds so that the on-call engineer receives a signal before users report the problem.
- Testing on the staging environment. We run scenarios with artificial failures and delays, and make sure the signal reaches the system, is grouped correctly, and lands in the right alert. We separately check behavior under poor network conditions and offline.
- Handover to operations. We hand over the configured system with an on-call procedure, a description of typical incidents, and an action sequence, and train the team to read dashboards and analyze failures using traces.
After handover, the system continues to evolve: collection rules and alert thresholds are revisited as the application grows, so that monitoring does not turn into noise.
Output artifacts: configurations, schemas, and regulations
Integrating Dynatrace ends not with an enabled agent but with a set of artifacts that allow the system to be maintained without us.
Each item is handed over to the customer's repository and versioned alongside the application code — at the next release, it's clear what changed in the configuration and why.
- Monitoring configuration — files with metric collection settings, request tagging rules, and trigger thresholds. We separately document which events are considered incidents and which are background noise.
- Data flow schema — where metrics are collected from, which nodes they pass through, where they are stored, and for how long. With it, a new engineer understands within an hour where to look for the cause of a degradation.
- Access policies — a role matrix: who sees dashboards, who changes thresholds, who receives notifications. Access is granted on the principle of least privilege.
- On-call regulations — the procedure for when an alert fires: who receives the signal, within what time it must be acknowledged, when to escalate. With defined areas of responsibility between the application team and infrastructure.
- Runbooks for typical failures — step-by-step scenarios for common incidents: a growing share of failed requests, degraded response time on a specific screen, a broken integration with the backend.
- Dashboard map — which panels are viewed daily and which are opened only when investigating an incident. Without this, the on-call engineer drowns in graphs.
- Rollback procedure — how to remove or relax collection rules if they interfere with a release, and what is lost in observability as a result.
All of this is delivered as working documentation, not as a report "for the sake of a checkmark": it is updated with every change to the application. Describe your task — we'll come back with an estimate and a plan for which artifacts you specifically need.
Case study: how we reduced the time to find the cause of failures
The project is a mobile bank with a million-strong audience on iOS and Android.
Complaints about "freezes during payment" were coming into support, but they could not be reproduced: logs were spread across the client and the backend, and there was no correlation between the user session and the request to the service.
Engineers spent an average of 6-8 hours localizing the cause, and in half the cases the incident was closed as "cannot reproduce."
What was changed
We implemented Dynatrace as a unified application performance monitoring system: we linked client sessions to server transactions with an end-to-end identifier, and enabled automatic tracking of network calls, crashes, and "frozen" screens.
We set up alerts for key business scenarios — login, payment, transfer — tied to a specific app version and device model.
What the result was
The time to localize the cause of a failure dropped from 6-8 hours to 20-40 minutes: an engineer opens the problematic session, sees the entire chain — from the button press to the service response — and immediately understands where the bottleneck is.
The share of incidents closed as "cannot reproduce" fell from 50% to 8%. We also gained separately on releases: before rollout we compare the metrics of the new version with the previous one and catch degradation before users notice it.
Two months after launch, the team stopped holding meetings for every failure — the data is already collected and tied to the scenario. Incident analysis turned from an investigation into reading a ready-made picture.
How is device monitoring different from server monitoring?
Server metrics describe the state of the backend: CPU load, API response time, queue depth, the share of errors on the service side. As long as these indicators are normal, the application is considered to be working.
But between the server and the phone screen lies a long path — the carrier network, the radio module, the device operating system, background processes, the build version. A problem arises at any of these segments, and the server simply does not know about it.
The observability gap is a situation where the server side responds in 200 milliseconds, but the user sees a frozen screen.
The causes vary: a weak signal in the subway, aggressive battery saving that stops background synchronization, a conflict with another app, a memory leak on a specific device model.
None of them are reflected in server metrics, because the request either never reached the server or reached it and was served normally.
Device monitoring looks at what is happening from the other side — from the side of user experience.
It records cold start time, scrolling smoothness, the share of interface freezes, app crashes, the duration of network operations on a specific communication channel, as well as a breakdown by device models and operating system versions.
It is this data that shows that the failure is reproduced among part of the audience with a certain configuration, rather than among everyone indiscriminately.
The key difference is in the measurement point and in whose experience it describes.
Server metrics answer the question "is the infrastructure coping," while device monitoring answers "is the person holding the phone in their hands satisfied." Both pictures are needed at the same time: the first shows the resources and bottlenecks of the backend, the second shows the real operating conditions that cannot be reproduced in a test environment.
Dynatrace APM links these two layers into a single chain: from the screen touch to the server response and back.
When a user complains about slow loading, the engineer sees at which segment time is lost — in the network, on the device, or in the service — and does not spend days searching for the cause blindly.
Without such linking, the team fixes a server that was already working, while the user experience continues to degrade.
Common technical concerns before starting
Before starting integration, the same questions almost always come up: will the app slow down, will modules have to be rewritten, will telemetry collection turn into a separate storage cost line. Below are the answers, straight to the point, without marketing.
Will monitoring slow down the app itself?
The agent's overhead is a fraction of a percent of frame render time and network operations. Telemetry measurement and sending happen on a background thread, in batches, not on every call.
In practice, the user won't notice a difference: cold start time and interface responsiveness stay within the margin of error.
If the app is already at its memory limit, the agent is configured for a reduced detail mode — we capture basic metrics first, and enable deep analysis selectively.
Is it compatible with our stack and OS versions?
The agent supports native and cross-platform apps, current mobile OS branches and their previous major versions. If some of the code is on a legacy framework, that's not a blocker: monitoring connects to the app layer, not to every module.
During the assessment phase, we check your device and version matrix against the supported list and tell you directly where there will be gaps in the data.
How much data will be sent, and how do we control it?
The volume depends on what you decide to collect. By default, aggregated metrics and traces are sampled rather than written in full. Retention rules are set in advance: raw data lifespan, sampling rate, filtering out noisy events.
This keeps the volume predictable, while still making it possible to debug a specific failure, because the necessary traces are retained.
Is telemetry safe — won't user data leak?
Telemetry does not include personal data: field masking and a ban on transmitting sensitive values are configured at the start. Transmission goes over a secure channel, and access to dashboards is role-based.
We agree on the retention and deletion policy with your requirements — this is part of the work, not an option after launch.
If any point still leaves doubts — describe your configuration, and we'll come back with an estimate and an integration plan.
Let's discuss your task and come back with a plan
To come back with a timeline estimate and an implementation plan rather than generalities, we need a minimum of inputs: the platform and OS versions the application supports, the current build and release cycle, the list of external services and internal modules, access to repositories and the test environment.
If there is already an APM agent or metrics collection in place, show us exactly what is being collected now and where data is being lost.
On the customer side, it is enough to designate one person who confirms priorities and answers architecture questions. The rest is our job.
In response, we prepare:
- a phased implementation plan: environment preparation, agent connection, data collection setup, instrumentation of key scenarios, output to dashboards;
- a scope of work with responsibility boundaries — what we do, what remains on the customer's side;
- a timeline estimate for each phase and the points where your acceptance is required;
- an instrumentation scheme for critical user paths: login, payment, checkout, synchronization;
- a list of metrics and alerts the team will receive at the output, with trigger thresholds;
- requirements for access, environments, and test accounts;
- a rollback plan in case the agent affects build stability or application behavior;
- a support policy: who responds to incidents after launch and how.
Describe the task — which failures are concerning you now, on which platforms and in which scenarios, and what result you consider successful. We will come back with a timeline estimate, scope of work, and an implementation plan you can use to make a decision.