Skip to main content
The Electron SDK associates main-process and renderer data with the same session, allowing you to analyze desktop runtime activity and page experience together.

​
Collection overview

Renderer page data is collected by @flashcatcloud/browser-rum and follows Web SDK data collection.

​
Distinguish main and renderer events

Main-process and renderer events use different source fields: Use this query to select every event produced by an Electron application:
Filtering on source:electron alone omits renderer data.
If a renderer event does not contain container.source: electron, it did not use the main-process bridge. See Why do I only see main-process data?.
In the console, the attribute panel of error details and session event details also surfaces a virtual process attribute in the “Other” attribute group, with the value “Main process” or “Renderer process”, to tell which process emitted the event at a glance; in the session event list, main-process events additionally carry a “Main process” chip.

​
Sessions

The main process owns the Electron application session lifecycle: Main-process background work does not extend or create a session by itself.

​
User identity

The main-process SDK creates a stable anonymous device identifier. After you call setUser(), main-process events and bridged renderer events carry the signed-in user identity. The renderer uploads Session Replay directly. When replay is enabled, also call flashcatRum.setUser() and flashcatRum.clearUser() in the renderer. See Identify the signed-in user for API usage.

​
Main-process view

The main process has no page routing. The SDK maintains one fixed view per main-process instance and associates main-process errors and network requests with it. The view uses these identifiers: Renderers still create page views according to Browser SDK rules. The main-process view does not include renderer Web Vitals or user action counts.

​
Errors and crashes

​
JavaScript errors

Main-process and renderer stacks are normalized to stable paths and can be restored with source maps. See Electron error symbolication.

​
Native crashes

Electron writes a minidump when a native crash occurs. Because the process has already terminated, the SDK reads and reports the crash on the next application start. Crash events include:
  • Crash type and process information
  • The crashed thread and other thread stacks
  • Loaded native modules
  • Operating system and CPU architecture
Without symbol files, native stacks show module names and addresses. After you upload matching Breakpad symbols, Flashduty can restore function names, file names, and line numbers.

​
Process termination

The SDK also observes renderer and Electron child process termination, including cases such as system termination, launch failure, or sandbox termination that do not produce a minidump. These events include process type, exit reason, exit code, and page URL, but no stack trace.

​
Main-process network requests

The SDK automatically collects main-process http, https, fetch, and net.fetch requests as RUM resources. Primary fields include:
  • Request URL and method
  • HTTP status code
  • Request duration
  • Trace ID and Span ID
Main-process resources use resource.type: native, distinguishing them from renderer fetch and xhr resources. The Electron SDK does not provide a full APM pipeline. Only HTTP spans become RUM resources; IPC and child-process command spans are not uploaded.

​
Upload and retry

Regular RUM events and Session Replay use different upload paths: As a result, main-process site, proxy, batchSize, and uploadFrequency do not change Session Replay upload behavior. Configure a self-hosted replay endpoint separately in the renderer.

SDK integration

Instrument the main and renderer processes.

Advanced configuration

Configure upload endpoints, user identity, and public APIs.

Error symbolication

Restore JavaScript and native crash stacks.

Troubleshooting

Diagnose missing data, bridge, and replay issues.