Crash reporting & monitoring

BuildStack captures crashes from your shipped app, groups them into issues, and alerts your team when something new breaks. It's built in — no third-party account needed, and it works whether or not you use a separate monitoring product.

Open a project → Monitoring to see crash issues, and the setup panel to wire reporting up.

Send crashes (no SDK to install)

Every project has a public ingest endpoint:

https://api.mybuildstack.com/api/crash/<projectId>/ingest

The project id in the URL is the key (like a Sentry DSN), so there's no token to manage. Point any HTTP client at it with a JSON body of message, stack, platform (ios or android), and an optional release.

The Monitoring tab gives you a drop-in reporter (crash-reporter.js) you can copy straight into a React Native or web app. Call it once at startup:

import { initCrashReporter } from './crash-reporter';
initCrashReporter({ platform: 'ios', release: '1.0.0' });

It installs a global handler for uncaught errors and unhandled promise rejections, and exposes captureException(error) for reporting by hand inside a try/catch or an error boundary.

Issues, grouping, and retention

Crashes with the same platform, message, and top stack frame are fingerprinted into one issue with an occurrence count and a last-seen time, so a repeating crash is one row, not thousands. Expand an issue to see its most recent stack trace.

Because stack traces can contain data from your end users, reports are kept for 90 days and then deleted automatically.

Email alerts on new issues

The first time a new crash fingerprint is seen, BuildStack emails your workspace members. Recurring crashes don't re-notify, so you hear about genuinely new breakage without being spammed.

Symbolication (readable stacks)

Release builds ship minified JavaScript, so raw stacks point at the bundle, not your source. Upload the release's source map and stacks resolve to your original files and line numbers.

In the Monitoring setup panel, enter the release, pick the platform, and upload the .map file. From then on, crashes on that release are symbolicated when you view them (the expanded stack is labelled as symbolicated).

• This covers JavaScript / React Native source maps.
• Native iOS dSYM and Android NDK symbolication are a later addition.
• Upload the map for a release before (or after) its crashes arrive — existing

crashes symbolicate on next view.