Flutter Observability

Make production failures diagnosable without collecting unnecessary user data. Preserve an existing Sentry, Crashlytics, OpenTelemetry, Dynatrace, Datadog, or other telemetry stack unless the user requests a migration.

Preflight

Read SDK constraints, entrypoints, flavors/environments, and the complete existing telemetry and delivery wiring before diagnosing a cause or prescribing changes: SDK initialization, error hooks, consent/privacy rules, network and navigation instrumentation, isolate usage, obfuscation, symbol retention/upload, CI, and release identity. Do not infer the root cause from dashboard symptoms alone. When repository or backend evidence is unavailable, lead with the exact artifacts and backend evidence still required, state that diagnosis remains pending, and keep any remediation conditional. Start from a concrete diagnostic question or incident; do not instrument every event by default.

Define a small operational event contract: stable event name, severity, timestamp, release/build, environment, platform, correlation identifier, outcome, duration where meaningful, and a bounded set of redacted attributes. Keep user content, tokens, credentials, payment data, and raw request/response bodies out of telemetry.

Every instrumentation plan must explicitly cover all five governance controls: redaction, consent, sampling, backend retention/access, and bounded offline buffering. State which controls live in client code and which must be verified in the backend; do not imply client configuration alone enforces retention or access.

Route the work

• For framework, root-isolate, child-isolate, and async error coverage, read error and crash capture.
• For structured logs, breadcrumbs, traces, correlation, sampling, redaction, and consent, read logging, tracing, and privacy.
• For choosing or preserving a vendor, release metadata, symbols, buffering, and end-to-end proof, read vendor and verification.

Load only the references relevant to the request.