Explore Observations in Langfuse Cloud Fast Preview (v4)
How to think about the new model
In v4, every operation your application performs — LLM calls, tool executions, retrievals, agent steps — is a first-class row in a single observations table. Think of it like a spreadsheet where each row is one operation, and you can slice by any column. The trace is just one column (trace_id) that groups related operations together, the same way session_id or user_id groups things.
As agentic applications grow more complex, a single trace can contain hundreds or thousands of operations. The old traces table showed one row per request — to find an expensive LLM call or a failed tool invocation, you had to open traces one by one and scan their children. With the observations table, you can query across all operations directly: find every GPT-4 call over $0.10, every retrieval that took more than 2 seconds, or every tool call that errored — without knowing which trace they belong to.
You will notice more rows in the table than before — that's expected. Each row is now one operation, not one trace. The key is to use filters and saved views to focus on what matters. Filter by observation name, type, or model to surface the operations you care about, then save that as a view. The filter sidebar shows available values with counts, so you can discover which models, observation names, or error levels are most common before committing to a filter.
For conceptual background, see the observation-centric data model. For broader release context, see the Fast Preview (v4) docs.
Common views
These are some of the most useful starting points. Each can be saved as a saved view for one-click access.
| I want to see… | How to filter |
|---|---|
| Key operations | Filter by observation name or type matching your most important operations |
| All LLM generations | Filter type = generation |
| Expensive LLM calls | Filter type = generation, sort by total_cost descending |
| Errors for a specific user | Filter by user_id and level = ERROR |
| Operations scoped to a session | Filter by session_id, sort by latency descending |
| All operations for one trace | Filter by trace_id |
| Model latency comparison | Filter type = generation, group by model in a dashboard or sort by model column |
| Cost, latency, or errors by dimension | Self-serve dashboards |
We recommend setting up 2-3 saved views for your most common debugging workflows so the observations table feels immediately useful to your team.
Upgrade checklist
Ingest with a v4-compatible setup
Use one of these ingestion paths so your data appears in the unified table in real time:
- Python SDK v4: migration guide
- JS/TS SDK v5: migration guide
- Direct OpenTelemetry ingestion: set
x-langfuse-ingestion-version: 4on your OTEL span exporter. If you use OTLP HTTP environment variables, addx-langfuse-ingestion-version=4toOTEL_EXPORTER_OTLP_HEADERS. See OpenTelemetry setup.
If you are still sending data via older SDK versions, or via direct OpenTelemetry ingestion without x-langfuse-ingestion-version: 4, traces can appear in the unified tracing table with a delay of up to 10 minutes.
Propagate correlating attributes across observations
Use the SDK propagation helpers to propagate correlating attributes across child observations:
- Python:
propagate_attributes() - JS/TS:
propagateAttributes()
This is very important for filters to work accurately.
Attributes such as userId, sessionId, tags, metadata, version, and traceName should be available on observations so you can filter one table by request-level context and still work at observation granularity.
See Add attributes to observations for the SDK implementation details.
Share feedback
We are still iterating on the unified tracing experience. If something feels confusing, missing, or slower than expected, share feedback via support.
FAQ
Why are observations delayed or missing in the unified table?
The most common reason is that data is still being sent via older SDK versions or through a direct OpenTelemetry exporter without x-langfuse-ingestion-version: 4.
In the new v4 experience, those setups can lead to multi-minute delays before traces show up in the unified table.
If this happens, upgrade to Python SDK v4 or JS/TS SDK v5, or add the ingestion version header to your OTEL exporter.
How can I get a focused view of my most important operations?
Create a saved view that filters by the observation names, types, or models most relevant to your workflow — for example, filter type = generation to see all LLM calls, or filter by a specific observation name to track a key step in your pipeline. Save 2-3 of these views and they become one-click shortcuts in the table header.
The table shows too many rows — how do I make sense of it?
This is the most common reaction when first switching to the observations table. As agentic applications grow more complex, a single trace can contain hundreds or thousands of operations — showing one row per trace was actually hiding the signal you need. The solution is filters and saved views — not scrolling. Start by filtering for the observation types or names most relevant to your workflow (e.g., "all generations," "errors only," or a specific agent step). Once you save 2-3 views that match your debugging workflows, the table will feel more focused than the old traces table, not less.
Can I get the old experience back?
Yes. For now, you can switch the v4 beta experience off in the UI and return to the previous tracing experience. This is temporary, though: the unified table will become the standard experience, so it is worth setting up saved views and instrumentation for the new model.
