One‑Line SDK Turns Electron Desktop Apps into Fully Observable Services

Problem

Electron applications have a monitoring blind spot: the main process often produces no logs, renderer‑process errors are scattered across network requests, and native crashes generate binary .dmp files that require a minidump parser and symbol service.

Challenges

Dual‑process architecture – The main process runs on Node.js while the renderer runs on Chromium. They are independent runtimes, so traditional front‑end RUM SDKs only cover the renderer.

Native crashes – Crashes produce a binary .dmp dump that needs a minidump parser and symbol service, which most front‑end teams are unfamiliar with.

Unreliable reporting paths – Network requests from a renderer can be interrupted when a window closes, causing loss of events at the moment of a crash.

IPC observability – Modern Electron apps use tRPC or similar frameworks for type‑safe main‑renderer communication, but performance, errors, and trace data for these calls are not monitored.

Solution – @arms/rum-electron SDK

A single init() call in the main process automatically enables full‑stack monitoring for both the main and all renderer processes.

Key design decisions

Main process as data aggregation hub – All events, whether from the main process or any renderer, are funneled to the main process via ElectronReporter and the arms:rum-bridge. The bridge ensures data is not lost even if a window closes or a renderer crashes.

Zero‑config automatic injection – The SDK listens to web-contents-created, BrowserWindow, and dom-ready events to inject the Browser SDK and IPC bridge without requiring changes to preload scripts or imports.

Single‑package distribution – Preload scripts, the Browser SDK, and the WASM crash‑parsing engine are bundled into one npm package; installing npm install @arms/rum-electron is all that is needed.

Core capabilities

1. Zero‑config injection

After calling init(), every BrowserWindow automatically collects page views, performance metrics, Web Vitals, white‑screen detection, API requests, long tasks, and user interactions.

import armsRum from '@arms/rum-electron';
armsRum.init({ endpoint: '<your-endpoint>' });

2. Rust‑WASM local crash parsing

The SDK uses the rust-minidump library compiled to WebAssembly via wasm-pack. Crash dump files are parsed locally after app restart, providing thread stacks, module lists, and system information without uploading raw dumps.

3. tRPC monitoring

Wrap a tRPC router with instrumentTRPC() to automatically add OpenTelemetry‑compatible RPC metadata ( rpc.system='trpc') to all procedures.

import { initTRPC } from '@trpc/server';
import armsRum from '@arms/rum-electron';
const t = armsRum.instrumentTRPC(initTRPC.create());
export const appRouter = t.router({
  greeting: t.procedure.input(...).query(...),
  chat: t.procedure.input(...).mutation(...),
});

4. Distributed tracing

Supports W3C Trace Context, B3, B3 Multi, Jaeger, and SkyWalking. Tracing headers are injected into outbound fetch requests and tRPC calls, enabling end‑to‑end traceability.

armsRum.init({
  endpoint: '<your-endpoint>',
  tracing: {
    enable: true,
    sample: 10, // global 10% sampling
    propagatorTypes: ['tracecontext', 'b3'],
    allowedUrls: [
      { match: /^https:\/\/api\.example\.com/, sample: 100 }, // core API 100%
      /^https:\/\/cdn\.example\.com/, // fallback to global 10%
    ],
  },
});

5. Memory‑leak sentinel

A three‑layer sampling strategy captures memory metrics with minimal overhead (<0.1% CPU). Every 10 seconds app.getAppMetrics() updates an in‑memory accumulator; every 30 minutes two events ( memory_max and memory_avg) are flushed (≈5 events/hour). On crash or exit the current memory snapshot is flushed immediately.

6. Multi‑layer exception protection

In the main process the SDK intercepts uncaughtException, unhandledRejection, and console.error. In renderers it captures front‑end exceptions, unhandled promises, and white‑screen events. All events are sent back via the IPC bridge, ensuring no loss even if a renderer crashes. The monkey‑patching is non‑intrusive and can be fully restored after removal.

Performance overhead

Benchmark data shows CPU usage below 0.1% and only a few events per hour for memory monitoring, making the SDK effectively negligible in production.

Comparison with alternatives

vs. Sentry Electron SDK – Sentry offers extensive community support and features such as session replay, but its coverage lacks native tRPC monitoring, local crash parsing, and fine‑grained data compliance. Over 75% of Electron developers use Sentry, yet it does not meet strict data‑sovereignty requirements.

vs. Generic front‑end RUM SDKs – Generic SDKs can only observe the renderer process. @arms/rum-electron provides a full‑stack view, including main‑process metrics, crash data, and IPC tracing.

Getting started

Environment – Electron ≥ 28 (the SDK uses session.registerPreloadScript(); older versions fall back to session.setPreloads()).

npm install @arms/rum-electron

import armsRum from '@arms/rum-electron';
import { app, BrowserWindow } from 'electron';

armsRum.init({
  endpoint: '<your-endpoint>',
  env: 'prod',
  version: '1.0.0',
});

app.whenReady().then(() => {
  const win = new BrowserWindow({
    webPreferences: {}
  });
  win.loadURL('https://your-app.com');
});

Optional tRPC instrumentation:

import { initTRPC } from '@trpc/server';
import armsRum from '@arms/rum-electron';
const t = armsRum.instrumentTRPC(initTRPC.create());
// define router as shown above

Applicable scenarios

Enterprise Electron apps (e.g., Slack, Discord, Notion, internal tools)

AI desktop assistants and coding tools that use tRPC for backend calls

Long‑lived desktop applications (IDEs, design tools, trading platforms)

Industries with strict data compliance (finance, government, healthcare)