Activity and diagnostics
Inspect operational records and prepare useful diagnostic information.
In this topic
Mellow has separate systems for usage analytics, crash reporting, and local activity inspection. Configure them independently. A local Insights record is not the same as an analytics event, and disabling usage analytics does not automatically disable crash reporting.
Review the controls
Open Privacy and find the data-collection controls. Review both usage analytics and crash reporting, then separately review Activity Log settings and retention. If the layout in your build differs, use management search for the control's name.
| System | Purpose | Consent behavior in the current implementation |
|---|---|---|
| Usage analytics | Aggregate product and feature usage | Opt-in; no events sent before consent |
| Crash reporting | Diagnose crashes and hangs | Enabled unless explicitly disabled, when the build contains reporting configuration |
| Activity Log / Insights | Inspect local requests and operations | Governed by its own local logging controls |
Build configuration matters. A source build without analytics or crash-service configuration does not start those services merely because a preference is enabled.
How usage consent works
The analytics service distinguishes an undecided preference from an explicit refusal. Before a decision, a bounded in-memory queue can hold events. If consent is granted, eligible pending events can be sent. If consent is declined or the process exits without consent, the pending data is discarded.
The queue is bounded to 64 pending events in the current service. This avoids unlimited memory growth before a decision. Once analytics is disabled, new events are not emitted through that service. This choice governs future emission; it is not a claim to erase data already delivered to an analytics backend.
The implementation routes events through a central service rather than allowing each feature to initialize its own analytics client. Debug and release builds use different tracking environments.
What analytics is designed to describe
Feature events describe categories and outcomes: attempts, refusal stages, run outcomes, and bucketed counts. For example, Computer Use can report whether a run was attempted or refused without including its goal or per-step screen content.
Remote model identifiers have a dedicated hashed representation in the telemetry service rather than being treated as arbitrary free-form labels. This reduces direct exposure of custom identifiers, but hashing should not be described as a guarantee that every possible value is anonymous.
Product analytics should not contain conversation bodies, private files, or service credentials. When diagnosing a suspected data issue, inspect the exact event and implementation rather than treating this intention as proof about an unrelated logging path.
Crash reports are independent
The crash service starts only when it is enabled and a reporting endpoint is configured in the build. Its preference defaults on in the current implementation. Turning it off closes the reporting service for further collection through that path.
Crash diagnostics can describe app version, environment, stack traces, and failure context. They serve a different purpose from feature adoption counts. Do not assume a crash report is identical to a manually exported log or a full conversation transcript.
The current implementation uses Aptabase for usage events and Sentry for crash reporting. These are service dependencies, not additional user-facing Mellow accounts you need to create to use local models.
Local activity records
Insights can help explain which provider or tool handled an operation and what failed. Review whether prompt and response bodies are enabled in the local log and how long records are retained. Local records can be sensitive even when they are not part of analytics.
When sharing diagnostics, inspect the export and remove private text, access keys, endpoint credentials, and unrelated user data. Prefer a narrow reproduction and the specific failed stage over a complete dump of the application profile.
Verify a preference change
- Set the intended usage and crash preferences separately.
- Close and reopen the settings area to confirm their visible values.
- Restart when testing persistence and confirm they remain set.
- For a source build, inspect whether service configuration exists before interpreting a lack of network requests.
- Keep local activity settings in the verification checklist if that is the data you intended to stop retaining.
Troubleshooting
Analytics is off but Insights still records activity: these are separate systems; change the activity log settings.
Crash reports still enabled after declining analytics: change the crash-reporting preference independently.
No reports arrive from a development build: check endpoint configuration and debug environment routing.
A toggle does not persist: check the actual profile and build being launched, then reproduce with the precise preference and app version.
See Storage for local retention and Privacy Filter for supported model-request redaction.
Continue exploring · Build with MellowHow Mellow fits together →Trace the app, local server, model services and execution boundaries.