Error Tracking Ruby

PostHog error tracking for Ruby

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

Reference files

• references/ruby.md - Ruby 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

• posthog-ruby is the Ruby SDK gem name (add gem 'posthog-ruby' to Gemfile) but require it with require 'posthog' (NOT require 'posthog-ruby')
• Use PostHog::Client.new(api_key: key, host: host) for instance-based initialization in scripts and CLIs
• In CLIs and scripts: MUST call client.shutdown before exit or all events are lost
• Use begin/rescue/ensure with shutdown in the ensure block for proper cleanup
• capture and identify take a single hash argument: client.capture(distinct_id: 'user_123', event: 'my_event', properties: { key: 'value' })
• capture_exception takes POSITIONAL args (not keyword): client.capture_exception(exception, distinct_id, additional_properties) — do NOT use distinct_id: keyword syntax