Telemetry & crash reports

RPFM ships two pieces of opt-out telemetry, both controlled from Preferences → Telemetry:

• Enable Usage Telemetry — anonymous counters of which actions get used, sent to PostHog. This channel also carries any user feedback you submit.
• Enable Crash Reports — automatic upload of panic reports and breadcrumbs to Sentry when RPFM crashes.

Both default to on. Both take effect immediately.

What gets sent

Usage telemetry

When enabled, RPFM increments per-action counters in memory and flushes them to PostHog (one event per distinct action, with the invocation count carried as a property) when the program shuts down gracefully (or, on the server side, when a session disconnects). The events are tagged with a source so server and UI activity can be told apart.

Each counter is just (action_name, count). There’s no payload, no path, no Pack name, no game, no persistent user identifier — just “Open PackFile happened 7 times in this session”. The distinct_id attached to each event is ephemeral: it’s regenerated every run from the process id and a timestamp, so it can’t be used to track you across sessions.

Examples of action names that actually appear in the codebase: Open PackFile Menu, Open PackedFile Full, Save Pack, Diagnostics Check, Cascade Edition, Optimize PackFile, Open In External Program, Merge Tables. They’re whatever string a rpfm_telemetry::track_action(...) call passes — there’s no central registry.

User feedback

RPFM has a User Feedback dialog you can use to send the developers a short message directly from the app. Submissions are posted to PostHog as a dedicated user_feedback event carrying your text. It rides on the same plumbing as usage telemetry, so sending feedback requires Enable Usage Telemetry to be on. Only what you type in the dialog is sent.

Crash reports

When enabled, RPFM:

• Captures panics as they happen.
• Writes a local crash report under the error/ folder.
• Uploads the crash report to Sentry, along with breadcrumbs (a structured trail of recent operations in the session).
• Tracks session start / session end so we can tell how often crashes occur per session.

Crash reports include the crashing thread’s stack trace, RPFM’s version, the OS family, and the breadcrumb trail. They do not include the contents of any open Pack, file paths, or anything else identifying.

In debug builds the Sentry guard is created with an empty DSN, so panics dump locally but don’t upload anywhere.

Local crash reports

Even with crash report uploads disabled, RPFM still writes panic reports locally under <config>/error/ as TOML files. They’re useful for filing bug reports yourself: when something crashes, look in error/, attach the file to a GitHub issue, and that gives the developers exactly what an automatic upload would have.

API surface

If you’re embedding rpfm_telemetry into your own RPFM-derived tool, the rpfm_telemetry API docs cover the full surface. The README in the crate has more on the design.