nuxt

PostHog error tracking for Nuxt

This skill helps you add PostHog error tracking to Nuxt applications.

Reference files

• references/nuxt.md - Nuxt error tracking installation (v3.7 and above) - docs
• references/fingerprints.md - Fingerprints - docs
• references/alerts.md - Send error tracking alerts - docs
• references/monitoring.md - Monitor and search issues - docs
• references/assigning-issues.md - Assign issues to teammates - docs
• references/upload-source-maps.md - Upload source maps - docs

Consult the documentation for API details and framework-specific patterns.

Before running install or build commands or editing the Nuxt config file, show the exact command or change to the user and get their confirmation.

Key principles

• Environment variables: Always use environment variables for PostHog keys and host URLs. Never hardcode them.
• Key separation: Only the public project token and host belong in public runtime config, which ships to the browser. Keep the personal API key used for source map upload in server side config or CI secrets, outside client code and committed files. Treat the inline values in the reference config example as placeholders and supply real keys from environment variables.
• 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. Source map upload sends original source code to PostHog and needs a personal API key, so confirm with the user before enabling it. Give that key only the scopes the docs require, keep it as a CI secret, and keep generated source maps hidden rather than publicly served.
• Manual capture for boundaries: Use captureException() at error boundaries and catch blocks for errors that don't propagate to the global handler. Keep the existing error handling in those catch blocks, such as rethrowing or returning as before.
• Sensitive data: Captured exceptions, messages, stack traces and custom properties are sent to PostHog. Keep secrets, tokens, personal data and request bodies out of captured exceptions and their properties, and redact such fields before capture.
• Dependencies: Install only the official @posthog/nuxt package named in the docs, check the package name for typos, pin the version and commit the lockfile.