From error to trace to replay

The reason to buy error tracking and APM from one product is not a bundle discount. It is a join key. 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 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), groups by project plus fingerprint, and stores events in ClickHouse with issue rows in Postgres. Status transitions are explicit. Search filters environment, severity, tags, and 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, opt into enableTracing. For replay, use @newtalaria/browser with error-triggered recording (default profile records on error, not every session).

What this is not

This is not a log platform. Info/debug events share the event meter; do not treat Talaria as GB/day log ingest. Replay is not a privacy-free screen recorder — mask inputs in the SDK. There is no native mobile crash pipeline. Custom fingerprint rules, merge/split, and a live notification bell are not the launch workflow.