Sentry¶

CroStream's crash reporting is built on Sentry. This page is the complete reference: what Sentry is, which of its features CroStream uses and when, where your data goes, and exactly what is removed on the way. For turning reporting on and off, use the Crash reporting guide; this page explains what happens behind that switch.

Where to find it¶

Open Settings and scroll to Crash reporting, below Updates.

Report a problem… is also in the tray icon's menu on every system, and under Help in the macOS menu bar. Those menus belong to your operating system and can't be shown in a screenshot here; see Desktop behaviour.

What Sentry is¶

Sentry is an error-monitoring service run by Functional Software, Inc. A program includes Sentry's code (its SDK); when something goes wrong the SDK packages up what happened and sends it to Sentry, where the developer sees it grouped with the same error from other people, with the version, the system it ran on and the steps leading up to it. Without that, the developer learns about a bug only when someone notices and writes it up, if they do.

CroStream uses it to find and fix bugs, in test builds especially, and to help you with a problem you report. Reports aren't sold or used for advertising; see the privacy policy.

Two Sentry projects¶

Sentry sorts what it receives into projects. CroStream has two, both under the developer's one Sentry organization:

The window never contacts Sentry itself. See How data travels.

What CroStream uses from Sentry¶

Sentry has many features. These are the ones CroStream uses, in Sentry's own words with a plain explanation.

Every feature needs the main switch. Performance tracing and Session replay are additional opt-ins and do nothing while it is off.

Issues and events¶

An event is one error report. Sentry groups similar events into an issue, so a bug hitting fifty people is one issue with fifty events. CroStream's events come from:

• a part of the app that fails (a panic, in Go's terms), with the name of the part that failed, goroutine, as a tag;
• anything CroStream logs at error level;
• an error in the window.

Events carry the stack trace (function and package names are kept so the developer can find the code), the version, your operating system and your Twitch account.

Logs¶

Besides errors, CroStream sends its ordinary log lines (information and above) while reporting is on. These are the same lines CroStream writes to its own log: what connected, what ran, what failed. Sentry shows them together with the errors around them. Attributes that name a person (such as a login or chat text) are dropped; see What is removed.

Breadcrumbs¶

An error alone often isn't enough to understand a bug, so each carries a trail. In the app's core it is the last 100 log lines at information and warning level, and the type of each recent event (for example follow), never what it contained: no chat text, no names, no payload. The window adds its own trail the SDK collects by default, such as navigation and requests (method, address and status, never a body). All of it is scrubbed the same way.

User¶

The report's user is the Twitch broadcaster you're logged in as: ID, login, display name and, once your Twitch login has the optional user:read:email permission, email. CroStream's core owns this: it sets it itself, replaces anything the window says about the user, and never sends an IP address. Logging out of Twitch clears it, and reports are then sent without a name. See Your Twitch account.

The panel always shows who reports are sent as, here crothers (crothers@example.com) (see the last panel in Settings and what they control). Until your Twitch login has the email permission, only the name is shown.

Tracing¶

With Performance tracing on, CroStream sends transactions: a name and how long it took.

One transaction in five is kept (a rate of 0.2). The window's requests to the browser-mode API carry a trace header so the two sides connect; the desktop app makes no HTTP calls of its own.

Session Replay¶

With Session replay on, the window records what it shows, like a screen video built from the page rather than pixels, and keeps only the moments around an error. No whole-session recordings are made (the session sample rate is 0; the on-error rate is 1: every error that happens while it is on).

• All text is masked, all inputs are masked and all media (images, video) are blocked, in the window, before the recording is sent.
• No console lines, no clicks list and no request or response detail (no headers or bodies) are included.
• The recording's code is a separate download (about 127 KB, as built) fetched only if you turn replay on.

With replay on, Report a problem… says so before you send:

User Feedback¶

Report a problem… sends a Sentry user feedback item: your message, who it is from, and the same breadcrumbs as an error. It goes with the replay if Session replay is on. Your wording is kept, apart from the removal of tokens and web address queries. See Report a problem.

When it goes through, the box says so:

If the report can't get out in about five seconds, it says that instead, keeps your text, and offers Try again:

Not used¶

CroStream doesn't use these Sentry features, and the relay drops their data if anything tried to send it:

• Profiling (code-level CPU profiles)
• Attachments (files sent with an error, such as your config)
• Cron monitors and check-ins
• Metrics
• Debug files and source uploads from your computer. The developer uploads the app's source maps from the release machine, which makes window errors readable; nothing of that is on your computer.
• Crash dumps of the native process.
• Hostname and module lists: both are turned off.

Settings and what they control¶

The panel shows each combination. The main switch alone sends errors, logs, breadcrumbs and your identity; the two options under it are separate:

Development builds, builds without crash reporting and runs switched off by the environment look different. Those states are shown in Troubleshooting.

All three keys default to off and are left out of the file while they are. See the settings file and Environment variables for the developer details, including CROSTREAM_SENTRY_DSN and CROSTREAM_SENTRY_UI_DSN, which point a test run at another Sentry project.

Changes apply immediately. Turning reporting off first sends what is already queued (for up to two seconds), then stops. The Crash reporting guide explains each switch for users.

Release and environment¶

Every report is tagged with where it came from, so the developer can tell a bug in a test build from one in the release you run.

How data travels¶

flowchart LR
    W[The window] -- "its reports" --> R["CroStream's relay<br/>/sentry/envelope"]
    A[The app's core] --> S[CroStream's scrubber]
    R --> S
    S -- "HTTPS, port 443" --> Y[Sentry, US region]

The local relay¶

The window's reports never go to Sentry directly. The window posts them to a path on CroStream itself, /sentry/envelope (in the desktop app, inside the window's own server; in browser mode, on the same server as the web UI). The relay is a one-way gate:

• Refuses everything while reporting is off (answers "nothing to send"), so a window can't send while you've turned it off.
• Checks the destination. A report must name the window's own Sentry project; anything addressed elsewhere is refused, so it isn't a general proxy.
• Limits size and rate: at most 2 MB per report, and 60 at once then one a second.
• Keeps only what your settings allow. Performance items are dropped unless tracing is on, replay items unless replay is on, and every item type CroStream doesn't use (profiles, attachments, cron check-ins, metrics) is dropped always.
• Scrubs every text value with the same rules as the core, replaces the user with your Twitch identity, removes the computer's name and module lists, and tells Sentry never to infer an IP address.
• Forwards over HTTPS with a 10-second limit.

Where it goes¶

Everything is sent over HTTPS (port 443) to Sentry's US region, host o4512239177236480.ingest.us.sentry.io. There is no other server and no CroStream server in between.

Offline, slow and busy¶

• Offline or unreachable: the report isn't sent, and CroStream does not save it to retry later. It is lost; the next error is tried afresh. CroStream configures no offline queue, and the Sentry SDKs it uses do not keep one on disk by default. Nothing waits or blocks while this happens.
• Sentry asks for slower sending (a rate limit): the SDK obeys it and holds back. The relay passes Sentry's rate-limit headers on to the window so its SDK obeys too.
• Too many errors: CroStream spaces them itself.

A crash loop, then, can't use up the developer's quota or your network.

What is removed¶

All text CroStream sends passes through one scrubber in the app's core: the core's own events, logs and breadcrumbs, and everything the window sends through the relay. It runs on your computer. The rules, in order:

Besides text, whole fields are dropped, by name (any case), from log attributes, tags, extra data and contexts: login, user, username, display_name, viewer, chatter, chat, text, message_text, body, email, ip, remote, peer, host, cookie, authorization, and anything whose name contains token, secret, password, api_key or cookie. This is how chat text and viewer names stay out of logs: the value is not just masked but never included.

Also removed from every report:

• your computer's name (replaced with crostream) and the list of program modules;
• the values of variables in stack frames;
• cookies, request headers (but the browser name, from the user agent, stays for window errors), request bodies and the query of the page's address;
• for the window, the SDK's own idea of who you are, replaced by your Twitch identity.

Scrubbing twice changes nothing, so a value that has already been cleaned stays as it is.

Where it is stored, and for how long¶

Reports are stored by Sentry in its US region. How long Sentry keeps them, and on what terms, is Sentry's to say: see the Sentry privacy policy and its documentation on data retention. CroStream sets no retention of its own here and this page doesn't promise a figure. The CroStream side of this, including who can read reports, is in the privacy policy.

To have a report deleted, email contact@crostream.io.

Questions¶

Related¶

• Crash reporting
• Settings
• The settings file
• Privacy policy
• Sentry's privacy policy