Catch the crashes your testers never report.

Zero setup. The SDK installs the trap on construction.

When you create a PlayloopClient (TypeScript, Python, Unity, Unreal, Godot), the SDK installs a platform-appropriate crash trap and drains any crashes persisted from a prior run. Browser SDKs hook window.onerror and unhandledrejection. Node hooks uncaughtException. Unity hooks Application.logMessageReceived. Unreal hooks FCoreDelegates::OnHandleSystemError for OS-level crashes. Python hooks sys.excepthook and threading. Godot exposes Playloop.report_crash() for the engine error-handling paths GDScript can intercept.

Crashes are persisted to disk because the process is dying and can't ship live. The next game start drains the queue and flushes everything as crash_reported events. The server splits those into a separate session_crashes table, so your event stream stays clean.

The stack, the message, a ring of recent events.

Each crash report carries:

• Stack trace, as the runtime serialized it. Truncated at 16 KB.
• Exception message, the top-of-stack description (e.g. NullReferenceException or Cannot read properties of undefined).
• Build version, SDK version, platform string, carried forward from the crashed session so attribution survives even after the source session row is removed at the end of its retention window.
• Recent events ring, the last N events the SDK had buffered when the crash hit (default 5, configurable per game up to 50). Drives the “what was the player doing right before this?” explainer.
• Crashed-at timestamp, the moment the handler fired locally. Distinct from the report time (when the next session flushed the queue to the server).

Three knobs, all on the dashboard.

Find these under Settings > Events on each game. The SDK reads them on startup via the existing event-config fetch, so changes take effect on the next session start.

• Crashes enabled: master switch. Default on. Turn it off if you already run a dedicated crash reporter and don't want duplicate captures.
• Recent events count: how many events from the in-memory ring buffer to ship alongside the stack. Default 5, range 0–50. Higher means more context for the AI, but more disk on crash.
• Sample rate: fraction of crashes the SDK actually persists. Default 1.0 (everything). Drop this for very-high-crash games so the dashboard stays useful.

Crashes tab on every game.

/games/<slug>/crashes shows the grouped-by-signature list with a build filter. Each row links into a detail page keyed on the stack signature, so sharing the link survives recurrences. The detail page shows the latest occurrence, the full stack, and an Acknowledge button that dismisses every crash matching that signature for the game (rollup counts stay accurate; the suppression is presentational).

The game-tabs bar shows a red badge on Crashes with the unacknowledged occurrence count (capped at 99+). Sessions that ended in a crash get a small linked badge next to the status badge. Click through to the signature.

Upload source maps; the server resolves on ingest.

Browser games shipped through a bundler (Webpack, Rollup, Vite, Turbopack) produce minified stacks that are unreadable on their own. Upload the .map files alongside each build, and the server resolves every new crash automatically. Re-symbolication is fire-and-forget after ingest; the dashboard renders the resolved stack with a Show raw toggle.

Upload in CI after your bundler emits maps

for f in dist/**/*.map; do
  curl -X POST https://playloop.gg/api/v1/games/<slug>/symbols \
    -H "Authorization: Bearer $PLAYLOOP_MANAGEMENT_KEY" \
    -F "buildVersion=$BUILD_VERSION" \
    -F "platform=typescript-browser" \
    -F "files=@$f"
done

Re-uploads of the same bytes are no-ops (uniqueness key on gameId + buildVersion + platform + fileHash), so the loop is safe to bake into every CI run. Manage your uploads under Settings > Symbols on the game. Copy the curl snippet straight from there.

What “resolved” looks like

Before: at u (bundle.abc.js:1:12345)

After: at handleClick (components/my-component.tsx:42:7)

Groups that resolved to the same source line collapse automatically. A single bug across two build hashes shows as one signature, not two.

For Node servers

Heavy minification on server code is rare; Node 24 has --enable-source-maps on by default, so most Node stacks are already readable. Upload maps with platform=typescript-node if you need them.

Editor window. Bulk submit. Heuristic auto-fill.

IL2CPP retail builds strip method names and line numbers. Symbol files live on your machine alongside the build output; uploading 500 MB of symbol blobs per platform per build isn't practical. Instead, the Unity SDK ships an Editor window that resolves locally.

Playloop > Symbolicate Crashes

The flow:

• Paste your management key once (stored per-project in EditorPrefs, shared with the Event Config window).
• Click Fetch unresolved crashes. Rows whose stack already includes file + line (Editor sessions, Mono builds, Development Builds with Script Debugging on) auto-mark themselves READY and get pre-filled.
• For retail IL2CPP rows, click Resolve via shell tool… on each. The dialog accepts any local command (e.g. ndk-stack -sym /path/to/symbols for Android, atos -o build.dSYM/...for iOS). The raw stack is piped to the tool's stdin; its stdout becomes the resolved stack.
• Click Submit all ready. Every row with a resolved stack uploads in parallel. The dashboard's group list collapses any signatures that resolved to the same source positions.

Last-used commands are remembered per platform

Type ndk-stack -sym /Users/me/builds/0.4.9/symbols once. The next Android crash opens the dialog pre-filled. Type, run, done.

Ping a channel when a new bug shows up.

Paste a Slack or Discord incoming-webhook URL on Settings > Crash notifications and the next crash with a never-seen-before signature pings that channel with the error message, build, platform, and a deep link to the crash detail page.

Deduped by stack signature over 24 hours, so a crash storm against the same bug pings once per day. A different bug in the same window gets its own ping.

Slack

In Slack: workspace settings > Apps > Incoming Webhooks > Add to Slack > pick a channel > copy the Webhook URL. Paste into the Slack field on the settings page. Hit Send test to confirm the wiring.

Discord

In Discord: channel settings > Integrations > Webhooks > New Webhook > pick the target channel > Copy Webhook URL. Paste into the Discord field. Hit Send test.

What the message looks like

A header with the game name and the error. The build version and platform are listed underneath, and a button opens the crash detail page (where the dev can Acknowledge the signature to suppress further notifications).

What gets stored

The webhook URL is encrypted at rest (AES-256-GCM). The hostname is restricted to slack.com and discord.comdomains so a typo can't turn the field into an arbitrary outbound POST target. Private and loopback addresses are blocked at send time as defense-in-depth.

What works out of the box per SDK.

Crashes from a process that's already in the wrong state (deep native code corruption, OS-level forced kills, OOM) can't be captured by any user-space handler. Plan for most uncaught exceptions, not every termination.