Setting up Datadog APM: what breaks without tracing in production
A user writes to support: the app crashes during checkout. Monitoring shows a bare fact of failure: exception type, device model, build version.
Missing the main thing — the request path to the culprit operation: which screen was open, which call went to the server, how long it waited for a response, and what came back.
Without end-to-end tracing of a mobile app, an engineer sees only the edges: a crash on the device and a server record that is considered successful. Between them is a monitoring blind spot where network timeouts, response parsing errors, and main-thread hangs are lost.
Incident analysis via logs stretches over days: the build is reproduced on dozens of models, hypotheses are tested by brute force, and the bottleneck in production is never found — after release, the failure repeats for a different share of users.
The cost of blindness is not only team hours. Every unresolved crash on iOS and Android goes into reviews and lowers ratings in app stores, and the fix ships several releases later because the cause is unknown.
Planning also breaks: it is unclear what to fix first — network, response parsing, or memory on older devices.
We explain how this is closed with end-to-end tracing: link a client event to a server request so that an incident report is assembled in minutes, not days.
What end-to-end tracing of mobile apps gives
End-to-end tracing links a user action in the app to a specific request on the server: one identifier passes from a button press through a network call and database to the response.
The engineer sees not an abstract error but the entire path with the time of each segment — where the request was lost and at which step the latency grew.
For a mobile team, this changes three things at once. Defect localization time drops from days to hours: the build, OS version, and device model are tied to the same identifier.
The share of reproducible errors grows — instead of "it doesn't work for me," a trace arrives that can be opened and reproduced on the same scenario.
| What we measure | Before | After |
|---|---|---|
| Defect localization time | hours of manual log comparison | minutes: the request path is fully visible |
| Share of reproducible errors | some failures could not be reproduced | every failure has device and build context |
| Build quality control | problems were found from reviews | comparison of versions by failure rate and response time |
| Release monitoring | a release was rolled back after complaints | the spike is visible during rollout, rollback in advance |
Downtime is addressed separately: while a failure is visible only from complaints, downtime stretches until the first confirmed report.
A spike in errors on a specific version is noticeable already during a gradual rollout, so the release is rolled back before the failure becomes widespread. Datadog stores mobile and server data in one model, so moving between them does not require manual log comparison.
Data collection modes and fine-tuning sampling
The telemetry collection mode determines what will end up in tracing at all and what will remain invisible.
On mobile platforms, constraints are set by the runtime environment: background tasks sleep, the network disappears in the subway and roaming, and some buffers are lost during a crash. Therefore, data accumulates locally and is sent to Datadog APM in batches on the next app launch.
Below are three modes that teams realistically choose between at the start of implementation.
| Mode | When it fits | Limitations |
|---|---|---|
| Manual scenario instrumentation | Metrics are needed on several critical paths: login, payment, checkout | The rest of the code is not covered — a bottleneck outside instrumentation remains blind |
| Automatic collection for all calls | Initial diagnostics when it is unknown where exactly the degradation is | The volume of collected data grows proportionally to the number of requests, and battery consumption grows along with it |
| Hybrid with partial sampling | A production environment with a large volume of sessions | It requires discipline in setup: with an incorrect coefficient, rare crashes fall out of the sample |
The rule for choosing is one: manual instrumentation provides precision on important paths, auto-collection provides completeness of the picture.
In hybrid mode, set the sampling coefficient per user or per session, not per individual call — then the chain from app start to order confirmation remains coherent and does not break on random operations. We check the configuration on a test environment and see which scenarios did not reach storage.
How implementation proceeds: from audit to handover to the team
We build implementation in iterations: first we record what is already being collected, then we add the missing measurement points, and only after that do we link client events to server operations.
At each step, a working tool remains, not a set of settings that cannot be verified. We work in Datadog APM, but the sequence is the same for any observability tool.
- App monitoring audit. We analyze which events, failures, and metrics are already being collected, where context is lost between the user session and the server request, and which crashes are not visible at all.
- Measurement point scheme. We determine which actions we cover: launch, screen transitions, network calls, authorization, payment. We coordinate the list with your team — extra events create noise and inflate storage volume.
- Client-side changes. We set up collection on iOS and Android, and separately handle Flutter: some calls go through a shared layer, and it must be correctly linked to platform-specific ones.
- Server-side connection. We stitch client traces with server traces so that one slow request can be read in full rather than as two disconnected records.
- Testing on real scenarios. We run typical and emergency paths: connection loss, service failure, operation cancellation. We make sure the failure is visible and lands in the right observability dashboard.
- Project handover to the team. We leave configurations, the measurement point scheme, and short instructions, conduct training — after that, your developers add new events on their own.
Implementation artifacts: dashboards, policies, regulations
After implementation, the team is left not with a work report but with a working monitoring environment: app state is visible on dashboards, a degradation signal arrives without manual checks, and failure analysis follows a documented procedure.
We set up access to Datadog on your accounts — after handover, we do not remain the sole holders of keys and are not needed for day-to-day work with the system.
- App monitoring dashboards — launch time, share of unsuccessful sessions, UI hangs, breakdowns by OS versions and device models.
- Alerting rules — thresholds and averaging windows are selected so that the signal fires on degradation, not on a single outlier; each has a specified recipient and channel.
- Data access policies — roles, separation by environment, masking of personal fields, and their retention periods.
- Data flow diagram — from device to storage, with marked anonymization points and outputs to external systems.
- Connection instructions — how to bring a new app module into tracing without inflating the volume of collected events.
- Incident analysis regulations — levels, response times, report template, and the procedure for rolling back to the previous build.
- Ownership map — who on the team is responsible for dashboards, thresholds, and configuration updates.
The kit is designed for an engineer who has not worked with the project before: using these documents, monitoring can be brought up and configured from scratch without our help.
Case study: how we removed the blind spot in mobile release
The client came with the complaint "payment sometimes does not go through." The mobile client was a native part plus a shared cross-platform layer, and in production it lived as a black box.
They learned about failures from app store reviews and support emails, while logs contained an error without a link to a specific payment step: there was no way to check which of the three screens the user dropped off at.
We implemented Datadog APM so that one trace covered the path from button press to confirmation from the payment gateway.
The native and cross-platform layers were linked with a common request identifier, manual spans were placed on payment method selection, submission, waiting for a response, and confirmation, and network calls were moved to an interceptor that sets tracing headers.
Alerts were configured not for an "error in the app" but for a drop in the share of payments that reached confirmation.
Metrics before and after: the share of successful payments grew from 88 to 96%, and finding the cause of a specific failure shrank from two to three days to 25–40 minutes — tracing shows at which step and in which layer the chain breaks.
The share of failures caught before release rather than after grew from zero to the majority: the build goes through shadow traffic testing, and payment regression surfaces before rollout.
The client separately confirmed the effect: support stopped being the first line of diagnostics. Previously, an incident began with correspondence with the user; now it begins with a trace that already includes the platform, client version, and scenario step.
How does manual instrumentation differ from auto-instrumentation?
Manual instrumentation is the marking up of specific scenarios in code: checkout, login, catalog synchronization. The engineer sets the operation name, set of attributes, and measurement boundaries, so tracing shows the user's path, not the app's internals.
The price for this is discipline: a new scenario will not appear in the data until it is instrumented.
Automatic instrumentation works at the level of the platform and libraries: it intercepts network calls, database accesses, screen displays, and rendering time.
Coverage appears immediately, without changes to product code, but operation names are generated mechanically — "HTTP GET," "screen loaded" — and there is a lot of service noise in the stream.
The base on Datadog provides spans, but assembling a meaningful user path from them still has to be done manually.
App size is an argument against "enable everything": auto-collection pulls in modules and their dependencies, which is noticeable against app store limits and throttled loading. Manual instrumentation adds only your wrappers, and the build size remains predictable.
Release speed depends on where the change lives. For auto-collection, it is enough to update the library — there will be no new scenario instrumentation. The manual approach ties tracing to the release: a new user path means a code change, review, and build.
In practice, teams choose a hybrid — auto-instrumentation as a background, manual on critical paths, plus sampling and filters so that data volume does not grow faster than traffic.
Common technical questions about deployment and support
Before starting, engineering teams ask the same questions: how to embed Datadog APM into an already released app, whether battery consumption will grow, whether you can start with one platform, who will retain access, and whether the new collection will coexist with the current one. We answer each.
Can this be implemented in an already released app?
Yes: initialization at the entry point under a configuration flag, we do not touch the logic. We release to a share of users and compare cold start and session success.
How will this affect battery consumption?
We collect in batches with a local buffer, send while the screen is active and on Wi-Fi, background measurements are disabled. We compare a day of operation before and after enabling.
Can we start with one platform?
Yes. We connect iOS or Android separately — the naming scheme is shared, and the second platform is added without re-instrumentation. The Flutter layer is configured separately from the native parts.
Who will retain access after handover?
The account is registered to you, the keys are in your environment, and we work as invited participants. After handover, we revoke the roles; the data scheme and documentation remain with you.
Will this coexist with the current monitoring?
Yes. We delineate areas of responsibility and leave some signals in the previous system. Both streams run in parallel until we confirm that the metrics match.
Let's discuss the task and come back with an estimate and work plan
To keep the monitoring task analysis from boiling down to generalities, we need a minimal set of inputs. From them, it is clear where Datadog APM closes the gap between a failure and its cause, and where changes to app code or the build tooling will be required. Below is what to send for the initial analysis.
- App and platform composition: which modules remained native, what was moved into a shared layer, whether a single codebase is maintained on iOS and Android.
- Current monitoring tools: crash reporting, logs, manual measurements — what is already being collected and where it goes.
- Critical user scenarios: login, payment, checkout — the paths where a break costs the most.
- Access constraints: who owns the accounts, what security policies exist, whether a separate environment is needed for data.
- Privacy requirements: which fields are prohibited from being sent, whether filtering of identifiers and geolocation is needed.
- Release calendar: windows when changes to the build will not disrupt the release.
- Expected outcome: metrics, traces, network latencies, share of covered paths.
Describe the task — app composition, what monitoring you already have, and the timeline for your releases. We will come back with an estimate, a work plan, and a list of accesses that need to be granted before the start.