From error to trace to replay

When an exception, a waterfall, and a session recording share an identity, triage is a path. When they do not, it is three browser tabs and a guess. The join key is the product.

The problem

A raw event stream is unreadable by noon. Identical crashes differ by timestamp, user, and line noise in the stack. Without a stable identity you cannot assign, ignore, or resolve. With identity but no trace, you still cannot see the query that ran. With both but no replay, you cannot see the click that caused the client exception.

What it is

An event is one captured occurrence — exception or structured log. A fingerprint is a server-side identity for that failure. Clients never compute it. An issue is the grouped problem: counts, status (open / resolved / ignored), severity, first and last seen, optional assignee, comments.

Breadcrumbs are the trail before the event: navigation, console, network. Session replay is a retained rrweb recording of the DOM session, metered separately from events. Traces are the timed tree described in transactions and spans. Events may carry traceId, spanId, and replayId.

What it gives a team

• A shortlist instead of a firehose — the issue inbox.
• View trace and View replay on the event when those IDs exist.
• User and session context (userId, sessionId) so impact is not just event count.
• A place for alerts and AI to attach: new issue, reopened issue, or “explain this event.”

How Talaria does it

Ingest is events/ingest and ingestBatch. The server fingerprints (including a dedicated formula for network-shaped browser failures). The fingerprint includes environment, so the same stack in two environments is two issues. Each issue stores that environment, and issue detail lists the same problem in other environments. Events live in ClickHouse and issue rows in Postgres. Status transitions are explicit. The dashboard reads one environment at a time.

Replay is browser-only: rrweb segments upload through a dedicated API; the dashboard plays them with a console/network sidebar. Replay is a second billable meter (retained recordings), independent of events and of included performance transactions. PHP and Dart do not record sessions.

How to read it

• Open the issue, not the latest event, unless you need a specific stack or user.
• If View trace is available, read the waterfall before rereading the stack — the query is often not on the frame that threw.
• If View replay is available, watch the last seconds before the exception. Breadcrumbs on the event still help when replay was not retained.
• Resolve when the cause is shipped; a reopen means it came back, which is a different alert than a brand-new fingerprint.

Turn it on

Create a project, create an API key, send an exception with an official SDK or HTTP ingest — see Quickstart. For traces and replay, turn them on under Project settings. Replay uses @newtalaria/browser with error-triggered recording (default profile records on error, not every session).