Flutter Error Tracking installation

Install with the wizard

Run this command in your project directory to add PostHog to your Flutter project. The wizard detects your framework, installs the SDK, and sets up your first events.

Learn more

Or set it up manually by following the rest of this guide.

  1. Install the package

    Required

    Add the PostHog Flutter SDK to your pubspec.yaml:

    pubspec.yaml
    posthog_flutter: ^5.58.0
  2. Platform setup

    Required

    Add these values to your AndroidManifest.xml:

    android/app/src/main/AndroidManifest.xml
    <application>
    <activity>
    [...]
    </activity>
    <meta-data android:name="com.posthog.posthog.PROJECT_TOKEN" android:value="<ph_project_token>" />
    <meta-data android:name="com.posthog.posthog.POSTHOG_HOST" android:value="https://us.i.posthog.com" />
    <meta-data android:name="com.posthog.posthog.TRACK_APPLICATION_LIFECYCLE_EVENTS" android:value="true" />
    <meta-data android:name="com.posthog.posthog.DEBUG" android:value="true" />
    </application>

    Update the minimum Android SDK version to 21 in android/app/build.gradle:

    android/app/build.gradle
    defaultConfig {
    minSdkVersion 23
    // rest of your config
    }
  3. Send events

    Recommended

    Once installed, PostHog will automatically start capturing events. You can also manually send events to test your integration:

    Dart
    import 'package:posthog_flutter/posthog_flutter.dart';
    await Posthog().capture(
    eventName: 'button_clicked',
    properties: {
    'button_name': 'signup'
    }
    );
  4. Set up exception autocapture

    Recommended
    Client-side configuration only

    This configuration is client-side only. Support for remote configuration in the error tracking settings will be added in a future release.

    Dart AOT symbolication and background isolate listeners require posthog_flutter 5.58.0 or later. If your project uses an earlier version, set posthog_flutter: ^5.58.0 in pubspec.yaml and run flutter pub get.

    You can autocapture exceptions by configuring the errorTrackingConfig when setting up PostHog:

    Dart
    final config = PostHogConfig('<ph_project_token>');
    // Enable exception autocapture
    config.errorTrackingConfig.captureFlutterErrors = true;
    config.errorTrackingConfig.capturePlatformDispatcherErrors = true;
    config.errorTrackingConfig.captureIsolateErrors = true;
    // Requires SDK version 5.22.0 or higher
    config.errorTrackingConfig.captureNativeExceptions = true;
    config.errorTrackingConfig.captureSilentFlutterErrors = false;
    await Posthog().setup(config);

    Configuration options:

    OptionDescription
    captureFlutterErrorsCaptures Flutter framework errors (FlutterError.onError)
    capturePlatformDispatcherErrorsCaptures Dart runtime errors (PlatformDispatcher.onError). Web not supported.
    captureIsolateErrorsCaptures errors from the isolate where PostHog is set up. Spawn background isolates paused and call isolate.addPostHogErrorListener() before resuming them to capture their errors. Web not supported.
    captureNativeExceptionsCaptures native exceptions. Android (Java/Kotlin) and Apple platforms (iOS, macOS, tvOS).
    captureSilentFlutterErrorsCaptures Flutter errors that are marked as silent. Default: false.
  5. Manually capture exceptions

    Optional

    Basic usage

    You can manually capture exceptions using the captureException method:

    Dart
    try {
    // Your awesome code that may throw
    await someRiskyOperation();
    } catch (exception, stackTrace) {
    // Capture the exception with PostHog
    await Posthog().captureException(
    error: exception,
    stackTrace: stackTrace,
    properties: {
    'user_action': 'button_press',
    'feature_name': 'data_sync',
    },
    );
    }

    This is helpful if you've built your own error handling logic or want to capture exceptions that are handled by your application code.

    Error tracking configuration

    You can configure error tracking behavior when setting up PostHog:

    Flutter web apps use minified stack trace frames

    Flutter web apps generate minified stack trace frames by default, which may cause the configurations below to behave differently or not work as expected.

    Dart
    final config = PostHogConfig('<ph_project_token>');
    // Configure error tracking
    config.errorTrackingConfig.inAppIncludes.add('package:your_app');
    config.errorTrackingConfig.inAppExcludes.add('package:third_party_lib');
    config.errorTrackingConfig.inAppByDefault = true;
    await Posthog().setup(config);

    Configuration options:

    OptionDescription
    inAppIncludesList of package names to be considered inApp frames (takes precedence over excludes)
    inAppExcludesList of package names to be excluded from inApp frames
    inAppByDefaultWhether frames are considered inApp by default when their origin cannot be determined

    inApp frames are stack trace frames that belong to your application code (as opposed to third-party libraries or system code). These are highlighted in the PostHog error tracking interface to help you focus on the relevant parts of the stack trace.

  6. Upload Dart debug symbols

    Optional

    Flutter writes Dart debug symbols for release builds when you pass --split-debug-info. Upload the symbols for each build you ship so PostHog can show Dart function names and line numbers for Android and iOS exceptions. Add --obfuscate to the build command if you obfuscate your app.

    flutter build apk --release \
    --split-debug-info=build/posthog-symbols/android

    Run these commands from your app's root directory to upload each build's .symbols files. Sign in with posthog-cli login, or set POSTHOG_CLI_API_KEY and POSTHOG_CLI_PROJECT_ID in CI. Keep each build's symbols in its own directory.

    posthog-cli symbol-sets upload \
    --directory build/posthog-symbols/android

    To show source code context, use this command instead of the symbol-only upload. It includes your app's source files:

    posthog-cli symbol-sets upload \
    --directory build/posthog-symbols/android \
    --include-source --source-root ./lib

    --source-root ./lib limits source files, not symbol files. Run the upload on the build machine while your app source is available. Review your source files before uploading them. See the CLI debug symbol guide for more options.

  7. Future features

    Optional

    We currently don't support the following features:

    • Restoring obfuscated Dart exception class names
    • Capturing native C/C++ exceptions on Android (Java/Kotlin only)

    For symbolicated native Android and iOS stack traces, see the Flutter debug symbols guide.

  8. Verify error tracking

    Recommended
    Confirm events are being sent to PostHog
    Before proceeding, let's make sure exception events are being captured and sent to PostHog. You should see events appear in the activity feed.
    Activity feed with events
    Check for exceptions in PostHog
  9. Upload source maps

    Required

    Great, you're capturing exceptions! If you serve minified bundles, the next step is to upload source maps to generate accurate stack traces.

    Let's continue to the next section.

    Upload source maps

Still have questions?

Was this page useful?