What Datadog is
Datadog is an observability and security platform for cloud applications, made by Datadog, Inc., a company headquartered in New York and listed on Nasdaq. Launched in 2010, it brings infrastructure monitoring, application performance monitoring (APM), log management, monitoring of web and mobile apps, and security into one hosted service.
Its Real User Monitoring follows each session in a web or mobile app, with crash reporting, error tracking and session replay, and links the requests an app makes to your servers with the server traces behind them. Datadog publishes its own Flutter SDK, datadog_flutter_plugin, for iOS, Android and web apps, and keeps each organisation's data on one regional site, EU1 in Germany among them. A slow screen and the server work behind it meet in one view, which is why it is one of the crash, error and performance monitoring tools our analytics and monitoring module connects to.
What it does in your platform
Analytics & monitoring
Watches your mobile apps, web apps and servers in one place: crashes, errors and slow screens in the apps, and the traces and logs of the server requests behind them, so a failed transfer leads your engineers straight to its cause. Every event identifies a customer by the random platform ID alone. Personal data is removed on the phone and on the server before sending, and Datadog's Sensitive Data Scanner looks for anything that slipped through before it is stored.
How the connection works
Datadog's own Flutter SDK, datadog_flutter_plugin, goes into the apps together with its tracking HTTP client for calls to your API, and Datadog's Browser SDK goes into the web apps. On the servers, Datadog's tracing SDKs and the Datadog Agent, open-source software that runs on them, send traces and logs. Calls from the apps carry trace headers, so each screen and the server work behind it meet in Datadog.
Consent comes first
When the app opens, the Flutter SDK takes the customer's choice from the platform. If your data protection officer wants monitoring to wait for consent, the SDK starts as not granted and collects nothing, or as pending, keeping events on the phone until the customer decides: they are sent if the customer agrees and deleted if they decline.
A transfer stalls
A customer taps Send on a transfer and waits. The SDK records the screen, the tap and the call to your API with its timing, and adds trace headers to the call. It knows the customer only by the random platform ID, and if the phone loses its connection, events wait on the device until it is back.
The server is traced too
On the server, Datadog's APM follows the same request through the platform's services and database calls, and the logs written along the way carry the same trace ID. Before a trace leaves the server, the Datadog Agent replaces any value that looks like a card number, a check that is on by default.
Personal data stays out
On the phone, the SDK's event mappers strip personal data from error messages and URLs before anything is sent. With IP and location collection switched off in your application's settings, Datadog drops both when events arrive, and Sensitive Data Scanner redacts anything that still looks like a card number, IBAN or email address before it is stored. If your team turns on session replay, still in preview for Flutter, it masks all text and images and hides touches by default, and card and identity screens are hidden in full.
Datadog groups and alerts
The call times out, and the app records an error with the device, the operating system, the app version and, where there is one, the stack trace. Error Tracking groups it with the same error from other phones into one issue, showing how many customers it touched and when it first appeared, and a monitor notifies your engineers by email, in team chat or through your on-call tool. Crashes take the same path, sent the next time the app starts and made readable by the symbol files each build uploads.
From the screen to the cause
From the issue, engineers open the customer's session, follow the slow call to its server trace and logs, and see which service or query held it up. Once the fix ships, Deployment Tracking compares the new version's errors and crash rate with earlier ones, and an error that returns in a later version sends the issue back for review, tagged as a regression.
Next to other providers
Datadog is one of the module's crash, error and performance monitoring connectors, alongside Sentry, Firebase Crashlytics, New Relic and BugSnag. Where Mixpanel, Amplitude, Google Analytics for Firebase or PostHog tell your teams what customers do, Datadog tells your engineers how the apps and servers held up while they did it. All of them know a customer by the same random platform ID, so a slow transfer can be followed across tools without revealing who made it.
Your platform, not Datadog, decides what an event may carry, how versions are named and which ID stands for each customer, and the server's tracing can use OpenTelemetry, the open standard Datadog also accepts. Changing to another monitoring tool later means a different SDK in the next release of the apps; what customers see and use in them does not change.
When Datadog fits best
A strong fit when
- You want a slow or failed screen in your apps linked to the server request, trace and logs behind it.
- Your engineers already watch your servers and infrastructure in Datadog, and want the apps in the same place.
- You want the SDK to hold monitoring data on the phone until the customer agrees, and delete it if they decline.
Also worth a look
- Sentry or Firebase Crashlytics, when crash and error reports from the apps are what your engineers need most.
- New Relic, or a monitoring tool your team already runs for its servers, connected the same way.
How we get you live
The contract
We help you put your Datadog account and contract in place, signed together with Datadog's Data Processing Addendum and the EU's Standard Contractual Clauses it includes. Your security team can ask for access to Datadog's self-service trust portal, which holds its SOC 2 Type 2 report and ISO 27001 certificate.
The data
We create your organisation on Datadog's EU1 site, in Germany, and switch off the collection of client IP addresses and geolocation in your application's settings. Sensitive Data Scanner gets rules for card numbers, IBANs, email addresses and IP addresses, retention filters keep the traces of failed and slow requests, and what an event may carry goes on the tracking plan your team reviews.
The keys
App credentials and server credentials stay apart. The apps carry a client token, which Datadog provides for apps because it can only send data in, while the API key lives with the Datadog Agent on your servers. The key that uploads symbol files is kept in your build pipeline's secret store, never in an app.
A full test run
Before your first real customer, we break things on purpose in a separate test environment: crashes, failed calls and slow requests from every app and the server. Your team then sees readable stack traces, each session linked to its server trace and logs, and no personal data in any of them.
