> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryopencomputer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up tracing and call events

> Connect Langfuse traces and BigQuery call diagnostics, then check delivery.

Use **Platform Settings** for organization-level telemetry. Traces, call-event diagnostics, and [workflow webhooks](/guides/webhooks.md) are different integrations with different payloads and delivery behavior.

## Connect Langfuse

1. Open **Platform Settings → Telemetry**.
2. Enter **Host**, **Public Key**, **Secret Key**, and **Project ID** for your Langfuse project. The project ID identifies the project in trace links.
3. Leave **Make traces publicly viewable** off unless you intend anyone holding a trace URL to view its contents, including conversation and tool data.
4. Choose **Save**. After an eligible controlled call, inspect its trace in the intended Langfuse project and correlate it with the Athena run.
5. Use **Remove** if the organization should stop using those credentials. Removal is separate from deletion of previously exported traces at the destination.

A successful settings save is not a trace-delivery test. If a trace is missing, check project identity, host, provider access, and the run's telemetry support. Do not enable public traces merely to troubleshoot authentication.

## Prepare a BigQuery call-events table

Use an existing table whose schema matches the columns below. The service identity needs permission to read the table schema and insert rows. Use nullable, non-repeated columns; additional columns must not be required unless Athena can populate them.

| Column | Type |
| - | - |
| `ts` | TIMESTAMP |
| `event` | STRING |
| `run_id`, `org_id`, `workflow_id`, `turn` | INTEGER / INT64 |
| `severity` | STRING |
| `value_ms` | FLOAT / FLOAT64 |
| `node_id`, `node_name` | STRING |
| `detail` | JSON or STRING |

For example, replace this illustrative table identifier with your own project, dataset, and table before running it in your BigQuery environment:

```sql theme={null}
CREATE TABLE `your-project.athena.call_events` (
  ts TIMESTAMP,
  event STRING,
  run_id INT64,
  org_id INT64,
  workflow_id INT64,
  turn INT64,
  severity STRING,
  value_ms FLOAT64,
  node_id STRING,
  node_name STRING,
  detail JSON
);
```

## Connect the event destination

1. Open **Platform Settings → Call events** and choose BigQuery as the destination.
2. Set **Table** to `project.dataset.table`.
3. Choose **Service account**, then enter its **Service account email** and **Private key** in the secure form. If **Deployment identity** is offered and provisioned for your account, it uses the hosted deployment's identity instead.
4. Choose **Test connection** and resolve schema or permission errors. The connection check does not prove a completed call exported its events.
5. Enable **Export call events** and save. After a controlled call, query the destination for its run ID and inspect the expected diagnostic events.

Saved private keys are masked; leave the masked value unchanged to retain the current key. Diagnostics can include stage latencies, silence events, and call outcomes. Avoid treating a call with no applicable event as evidence that every exporter stage failed.

## Delivery and changes

Call-event delivery makes up to three attempts in a bounded window. Events can be discarded after delivery failure, a destination change, or queue exhaustion. This is not an unlimited durable queue and does not provide exactly-once delivery. Destination retries use best-effort deduplication; do not build an exactly-once assumption around the exported rows.

Disable export or remove the destination to stop future use, then check the saved state. Previously exported records remain at the destination. Workflow-webhook retry/dead-letter rules are separate; see [Webhooks](/guides/webhooks.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.