Error reporting

Stackie can report a small, predefined error classification to help us identify and fix failures. Error reporting is separate from local logs. Stackie does not currently provide a written feedback or user-submitted report channel.

Customer-machine reporting starts off. Where reporting is available, Stackie offers these choices:

Report once sends one eligible error after you approve that report. The one-time choice is consumed before Stackie attempts delivery, so a failed network request does not silently become continuing permission.
Report automatically permits future eligible errors while your current notice and preference remain valid.
Do not report keeps Sentry reporting disabled.

You can withdraw automatic reporting in Stackie settings. Withdrawal closes the owned reporting client and blocks later initialization and transmission. It does not remove information that was lawfully sent earlier; use the privacy rights contact in Stackie’s current Privacy Notice for an access or deletion request.

What an error report can contain

Sentry reports are constructed from a fixed, versioned list. Depending on the surface and error, that list can include:

a Stackie-owned error code and fingerprint;
component, severity, environment, and release categories;
an opaque random event or correlation identifier;
for JavaScript failures, up to 32 compiled frames containing only a reviewed module class, an approved same-origin compiled asset path or fixed Worker bundle name, and bounded line and column numbers.

Stackie evaluates consent and activation gates before the Sentry software is initialized. It validates each report before transport and again before network egress. A report that does not match the approved structure is dropped.

What is never included in Sentry

Sentry reporting does not accept raw error objects or messages, function names, unrestricted stack traces, local variables, original-source or filesystem paths, customer-controlled or cross-origin URLs, query parameters, command arguments, environment values, credentials, secrets, logs, request or response content, cookies, headers, database statements, account or customer identifiers, customer content, screenshots, DOM content, attachments, replay, or free-form written feedback.

Bounded sampled traces and low-cardinality performance metrics may operate in approved dev, PPT, and live releases. The embedded dashboard may send aggregate release-health counts, and Cloud runtimes may send fixed scheduled check-ins. Private JavaScript maps may be uploaded from protected build pipelines so the compiled coordinates above can be symbolicated. Profiling and Seer/AI are not integrated.

Availability

The base integrations are delivered behind independent environment, consent, privacy, security, retention, credential, and release gates. A reporting option may remain unavailable until the gates for that surface pass. Dev, PPT, live, and customer-machine reporting are independently controlled. Temporary per-spec branches remain credentialless and reporting-disabled; there is no standing branch-reporting environment or destination.