Error Tracking Flutter
PostHogOfficialCreated by PostHog
- Skill
- Tool integration
- Data and AI
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides guidance on integrating PostHog error tracking into Flutter applications. It covers the implementation of exception autocapture, manual error boundary handling, and the importance of uploading source maps for readable stack traces. The skill also details how to manage issues through assignment rules and configure alerts to stay informed about application stability.
What it does
- Guides the integration of PostHog error tracking into Flutter apps
- Explains how to enable exception autocapture for automatic error reporting
- Provides patterns for manual error capture at boundaries
- Details how to upload source maps for unminified stack traces
- Describes how to set up automated issue assignment and alerting
- Outlines best practices for environment variable usage and SDK initialization
When to use it
- When you need to monitor runtime errors in a Flutter application
- When you want to automate the triage and assignment of reported issues
- When you need to receive notifications for specific error spikes or new issues
- When you need to resolve minified stack traces to original source code
Advantages
- Centralizes error reporting and management within the PostHog platform
- Supports automated workflows for team-based issue assignment
- Enables proactive monitoring through configurable spike and trend alerts
- Maintains clean code by recommending non-intrusive error handling patterns
Usage examples
- “How do I set up PostHog error tracking in my Flutter app?”
- The agent provides steps to initialize the SDK, enable autocapture, and ensure environment variables are used for configuration.
- “How can I notify my team when a new error occurs in Flutter?”
- The agent explains how to configure alerting rules in the PostHog error tracking dashboard to send notifications to Slack or other channels.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/posthog/error-tracking-flutter/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip error-tracking-flutter.zip -d .agents/skills
Documentation by PostHog
PostHog error tracking for Flutter
This skill helps you add PostHog error tracking to Flutter applications.
Reference files
references/flutter.md- Flutter error tracking installation - docsreferences/fingerprints.md- Fingerprints - docsreferences/alerts.md- Send error tracking alerts - docsreferences/monitoring.md- Monitor and search issues - docsreferences/assigning-issues.md- Assign issues to teammates - docsreferences/upload-source-maps.md- Upload source maps - docs
Consult the documentation for API details and framework-specific patterns.
Key principles
Environment variables: Always use environment variables for PostHog keys and host URLs. Never hardcode them.
Minimal changes: Add error tracking alongside existing error handling. Don't replace or restructure existing error handling code.
Autocapture first: Enable exception autocapture in the SDK initialization before adding manual captures.
Source maps: Upload source maps so stack traces resolve to original source code, not minified bundles.
Manual capture for boundaries: Use
captureException()at error boundaries and catch blocks for errors that don't propagate to the global handler.
Framework guidelines
No specific framework guidelines.
Files
- ATTRIBUTION.mdAdded by AutoGineer966 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md1.4 KiB
- references/alerts.md4.1 KiB
- references/assigning-issues.md5.5 KiB
- references/fingerprints.md3.4 KiB
- references/flutter.md9.1 KiB
- references/monitoring.md8.6 KiB
- references/upload-source-maps.md2.7 KiB
references/fingerprints.md
Fingerprints - Docs
Every captured exception is assigned a fingerprint. This fingerprint is used to group similar exceptions into issues. This page covers how fingerprints are generated, how they're used, and how you can override them when capturing exceptions.
Fingerprint and issue grouping
Every exception has a fingerprint, whether generated or defined by the user. Each fingerprint links to exactly one issue. Exceptions that share the same fingerprint define an issue.
Multiple different fingerprints can point to the same issue (a many-to-one relationship) if you merge issues.
How are fingerprints generated?
Fingerprints are built iteratively using components of the exception event. The flowchart below shows how fingerprints are generated.
flowchart LR A[Add exception type to fingerprint] --> B{Stack trace<br/>available?} B -->|No| C[Add error message to fingerprint] C --> D[Final fingerprint] B -->|Yes| E{In-app frames<br/>exist?} E -->|No| F[Add first frame to fingerprint] E -->|Yes| G[Add in-app frame to fingerprint<br/>Priority: resolved > unresolved] F --> D G --> D
The flowchart in text
Fingerprints are generated by considering the following in combination:
The exception type
If there's no resolved stack trace, add the error message to the fingerprint
If there are stack traces but no in-app frames (frames from your code, not a dependency), use the first frame of the stack trace
If there are stack traces, in-app frames, and source maps available, use the resolved in-app stack frames
If there are stack traces, in-app frames, and source maps not available, use the first in-app stack frame
In some languages, like Python, one error can trigger another, creating a chain of linked exceptions. PostHog records the entire chain in the event and generates a single fingerprint for it.
Ensuring accurate fingerprints
Resolved stack traces are critical for accurate fingerprinting. Without accurate stack traces, PostHog cannot group exceptions consistently. If you have not uploaded source maps, follow the source map guide to do so.
This also means that if the exception type or message changes from one version to the next, the fingerprint will change.
When are generated fingerprints used?
Fingerprints are used to group similar exceptions into issues automatically. Automatic issue grouping is only done when:
No issue grouping rules are applied
No issue merging has been configured
No custom fingerprint is set during capture
You can find details about how issue grouping works in the issues and exceptions guide.
Customizing fingerprints
Fingerprints can be manually set during exception capture. This is a very useful way to group exceptions that are not related to each other. You can find examples of how to do this in the custom issue grouping section.
You can also learn more about grouping issues using rules in the grouping issues guide.
Community questions
Ask a question
Was this page useful?
HelpfulCould be better
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- PostHog
- Publisher
- PostHog (Official)
- Source
- PostHog/skills · skills/posthog/error-tracking/skills/flutter · commit a5d30e7
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- PostHog/skills
AutoGineer is not affiliated with or endorsed by PostHog.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download error-tracking-flutter.zip