Learn

Learn the product, not the jargon.

Start with the instrumentation course — or hand the install to an agent — then read the signal guides. Errors, traces, analytics and replay, explained against the dashboard you will actually use.

Course · 8 chapters

Instrumenting an app.

A course on the whole stack — errors, traces, analytics and replay — and which call to make in application code.

Start the course

01Instrumenting an appFour signals, one checkout, and a rule for every line of application code: capture, span, track, breadcrumb — or leave it alone.02Which call to makeThe chapter you keep open while you write. A failure, an intent, a duration or context — pick one call, or none.03Errors in application codeTalaria events are exceptions and the rare message that should become an issue. Everything else is a breadcrumb, a span or stdout.04Tracing in application codeA transaction is the request. A span is a timed child. You name the route, you opt in and you let auto instrumentation do the dull work.05Analytics in application codeName the intent, fire it once, identify the person and put the charge on the server.06A checkout, end to endOne purchase, every hop, the actual calls. This is what “instrumented” looks like when you are done.07One incidentMonday: the funnel drops at checkout. You follow the person, the replay, the issue and the query.08The operating modelDone is not more calls. It is a short checklist, a naming page in the repo and a weekly hour on the money route.

Guides

Read the signals.

5 guides

Signals

What performance measures — traces, waterfalls, RED and sampling — and how to read each one.

What SDK-native APM actually isTransactions, RED, traces, Web Vitals and release health — measured inside the request.Transactions, traces and spansA trace is one request’s path. A span is a timed unit of work. A transaction is the root span Talaria meters.How to read a request waterfallThe critical path is the longest chain of parent-to-child work — that is usually the fix.RED metrics: rate, errors, durationHow often it is called, how often it fails and how long it takes.Sampling you can explainKeep every failing transaction. Sample a tenth of the rest. Bill the root, not every query.

4 guides

In the request

The work inside a transaction: databases, outbound HTTP, Web Vitals and W3C context.

Slow queries and N+1Most “the database is slow” incidents are the app asking the same question too many times.External dependenciesEvery outbound call is a peer. Watch its error rate and p95 like your own routes.Web Vitals from real usersLCP, INP and CLS recorded from the browser SDK as spans on real sessions — not a lab crawl.Distributed tracing with W3C Trace ContextOne trace ID from the browser, through the API, into the query that failed.

6 guides

Product analytics

What people do in your app, and how Talaria keeps it private by default.

What product analytics actually isError tracking tells you what broke. Analytics tells you what people were trying to do.Events and propertiesFour kinds of call, one envelope and a property bag you control.Visitors, sessions and identifyThree ids doing three jobs. Get them straight and every number makes sense.Funnels and drop-offWhich step loses people — then the people, and the replay of them leaving.UTM and attributionWhere someone came from, captured once and stamped on everything they do next.Privacy and consentExactly what Talaria stores, and what it refuses to.

4 guides

Triage loop

How issues, replays, releases, alerts and dashboard AI turn a slow request into something you can own.

Release healthTag events with a release, then read crash-free rate instead of guessing from git tags.From error to trace to replayTalaria joins grouping, traces and replay on one issue.Instrument with an agent AgentThe agent creates the project, mints a development key and checks the first event. You confirm each create.Performance alerts and AI on traces AgentAlerts notice when RED crosses a line. Dashboard AI and MCP read the same evidence.

Book

Instrument with clean architecture.

Structure the app in layers so business rules stay independent of the framework, the database and the screen. Then instrument it.

Read the book

See it on a real project.

Developer is $5 per month and includes 10,000 transactions, with events and replays metered separately.

Start for $5

Connect your agent Read the docs