Use Error Tracking from PostHog CLI

The PostHog CLI is how error tracking gets what it needs from your build. Stack traces arrive minified or stripped, so the CLI uploads the debug symbols that turn them back into real file names, functions, and line numbers – and tags each upload with the release that produced it.

This is a build-time and CI surface rather than a place you read issues. You triage and resolve issues in the web app or over MCP.

What you can do here

• Upload source maps – inject and upload JavaScript source maps so minified frames resolve to your real code. See Upload source maps with the CLI.
• Upload native debug symbols – Apple dSYM, Hermes for React Native, and Proguard/R8 mappings for Android, so native and mobile crashes symbolicate too. See Android mappings.
• Manage symbol sets – list and download the symbol sets already uploaded to your project.
• Tag releases – uploads made with posthog-cli sourcemap upload automatically create release information, so you can tie an exception back to the deploy that introduced it.

Uploads need a personal API key with the error_tracking:write scope. See the CLI docs for installation and authentication.

Run it in CI

Symbol upload belongs in your build pipeline, so every deploy ships readable stack traces. There's a ready-made GitHub Action, and framework integrations for Next.js and Nuxt handle the upload step for you.

Related

• PostHog CLI – installation, authentication, and the full command reference
• Stack traces – how symbolication works and why uploads matter
• Releases – tying exceptions to the deploy that caused them