AutoGineer
Generated banner for Error Tracking Web
Generated logo for Error Tracking Web

Error Tracking Web

PostHogOfficialCreated by PostHog

  • Skill
  • Tool integration
  • Data and AI
  • MIT
  • No issues found
Download ZIP

From the author

PostHog error tracking for Web (JavaScript)
— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides guidance on implementing PostHog error tracking within JavaScript web applications. It covers SDK initialization, manual exception capture, and best practices for managing error data, including the use of source maps for readable stack traces and proper user identification to avoid PII leakage. The skill also outlines how to configure alerts and automate issue assignment to streamline debugging workflows.

What it does

  • Initializes the PostHog JavaScript SDK for browser-based error tracking.
  • Enables automatic exception capture for monitoring application crashes and errors.
  • Provides methods for manual error capture at specific application boundaries.
  • Supports source map uploads to de-minify stack traces for easier debugging.
  • Configures automated issue assignment rules based on exception properties.
  • Sets up alert notifications for new, reopened, or spiking error issues.

When to use it

  • When you need to monitor runtime errors in a JavaScript web application.
  • When you want to automate the triage and assignment of software issues to team members.
  • When you need to receive real-time alerts for critical application errors or error spikes.
  • When you need to correlate frontend errors with user sessions and feature flags.

Advantages

  • Centralizes error monitoring and user behavior data in one platform.
  • Reduces manual triage time through automated assignment rules.
  • Improves debugging efficiency by resolving minified stack traces via source maps.
  • Helps maintain data privacy by distinguishing between event properties and user identification.

Usage examples

“How do I initialize PostHog for error tracking in my React app?”
The agent provides the posthog.init() code snippet, ensuring it is called before other methods and configured with environment variables for keys and host URLs.
“How can I alert my team when a specific error spikes?”
The agent guides you to the error tracking configuration page to set up spike alerts based on historical baselines or event volume.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/posthog/error-tracking-web/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip error-tracking-web.zip -d .agents/skills

Documentation by PostHog

PostHog error tracking for Web (JavaScript)

This skill helps you add PostHog error tracking to Web (JavaScript) applications.

Reference files

  • references/web.md - Web error tracking installation - 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.

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

  • Remember that source code is available in the node_modules directory

  • Check package.json for type checking or build scripts to validate changes

  • posthog-js is the JavaScript SDK package name

  • posthog.init() MUST be called before any other PostHog methods (capture, identify, etc.)

  • posthog-js is browser-only — do NOT import it in Node.js or server-side contexts (use posthog-node instead)

  • Autocapture is ON by default with posthog-js (tracks clicks, form submissions, pageviews). Do NOT disable autocapture unless the user explicitly requests it.

  • NEVER send PII in posthog.capture() event properties — no emails, full names, phone numbers, physical addresses, IP addresses, or user-generated content

  • PII belongs in posthog.identify() person properties (email, name, role), NOT in capture() event properties

  • Call posthog.identify(userId, { email, name, role }) on login AND on page refresh if the user is already logged in

  • Call posthog.reset() on logout to unlink future events from the current user

  • For SPAs without a framework router, capture pageviews with posthog.capture($pageview) or use the capture_pageview history_change option in init for History API routing

Files

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:

  1. The exception type

  2. If there's no resolved stack trace, add the error message to the fingerprint

  3. 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

  4. If there are stack traces, in-app frames, and source maps available, use the resolved in-app stack frames

  5. 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:

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.

Needs: Needs Node.js

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/web · 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 or PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download error-tracking-web.zip