How error tracking works
Crashes and the errors you already log, grouped by cause and joined to the same user's funnel — with no capture calls to write.
Your errors and your funnel end up in one place, keyed to the same user. Click an issue, see who hit it; click a user, see what they did before it happened. That join is the part a standalone crash reporter structurally can't do.
You don't write capture calls
| Python | Node | React Native | |
|---|---|---|---|
| Crashes | ASGI middleware | uncaughtException | global error handler |
| Failed awaits | — | unhandledRejection | promise rejection tracking |
| Errors you log | logger.error(...) | console.error(...) | console.error(...) |
| Explicit | capture_exception(e) | captureException(e) | Growth.captureError(e) |
The third row is the one that matters most. Most real failures — a vendor API timing out, a database call that fails over — are caught, logged, and never re-thrown, so a crash handler alone never sees them. If you already log errors when you catch them, you already have error tracking. Setup cost: two lines for a Python or Node backend, zero for a React Native app that already calls Growth.init().
How issues are grouped
Grouping happens on our side, from the raw stack. An issue is exception type + top few app frames + route. Line numbers are excluded, so editing code doesn't split an issue in two; dependency frames (site-packages, node_modules) are excluded, so one bug doesn't fragment into an issue per library that touched it. Log lines with no exception group on the call site instead — an f-string full of ids stays one issue.
Status and alerts
Issues move through new → ongoing → escalating, and you can resolve or ignore them. You're alerted on exactly three things: an issue nobody has ever seen, an issue that comes back after you resolved it, and one that spikes past its own 7-day baseline — today at least 10 events and more than 2× baseline. Not on every occurrence.
Uptime rides along
Point Fictura at one URL and it's pinged every 60 seconds; three consecutive failures flag it down, and the down/recovered alerts fire exactly once each through your alert connections. The Issues page shows 7-day uptime beside your error feed.
What we don't do
- Native crashes (iOS/Android) aren't captured — that would need a native module, and keeping installation to one
npm installis the trade we chose. Keep a crash reporter for these. - Minified stacks aren't symbolicated. Release-build JS errors group by normalized message instead — coarser, but stable across releases.
- No performance tracing, profiling, or session replay. Different products.
Running alongside an existing tool is fine and expected — our handlers always chain to whatever was installed before them, so nothing you have today stops reporting.