---
title: Why do I see HTTP requests or database queries in my Langfuse traces?
description: If your Langfuse dashboard shows spans like HTTP GET, SQL queries, or health checks alongside your LLM calls, here's why it happens and how to fix it.
tags: [observability, integration, observability-get-started]
---

# Why do I see HTTP requests or database queries in my Langfuse traces?

When your application uses other OpenTelemetry-instrumented libraries, you might see [observations](/docs/observability/data-model#observations-traces-and-sessions) showing up in Langfuse that aren't relevant for monitoring or improving the AI side of your app. They still count toward your [billable units](/docs/administration/billable-units), so you'll want to remove these from your Langfuse setup.

You can often recognize these spans by their names: `GET /api/...`, `sql`, `put_with_retries`, `/ping`, or similar.

  ![Langfuse traces list showing unwanted GET spans](/images/docs/faq-unwanted-http-database-spans.png)

## Why this happens

The Langfuse SDKs are built on [OpenTelemetry (OTEL)](https://opentelemetry.io/). The SDK attaches to the [**global TracerProvider**](/faq/all/existing-otel-setup#global-tracer-provider), which is a single hub that all OTEL-instrumented libraries in your app share. Every span from every library flows through every processor attached to that provider.

The Python v3 and JS/TS v4 SDKs have no automatic filtering — Langfuse exports all spans it receives, including HTTP requests, database queries, and framework internals. This issue is resolved in the Python v4+ and JS/TS v5+ SDKs, which apply a [default span filter](/docs/observability/sdk/advanced-features#filtering-by-instrumentation-scope) that automatically drops non-LLM spans.

```
┌────────────────────────────────────────────────┐
│            Global TracerProvider               │
│                                                │
│  All spans from all libraries:                 │
│  ├── LLM calls (OpenAI, Anthropic, ...)    ✅  │
│  ├── HTTP requests (axios, fetch, ...)     ❌  │
│  ├── Database queries (SQL, Redis, ...)    ❌  │
│  └── Framework spans (FastAPI, Express)    ❌  │
│                                                │
│  → ALL of these get sent to Langfuse           │
└────────────────────────────────────────────────┘
```

If you're on the Python v4+ or JS/TS v5+ SDKs, this problem should not occur as these versions filter out non-LLM spans by default. On older SDK versions, this typically happens when:

- You're using OTEL auto-instrumentation (e.g. `getNodeAutoInstrumentations()` in JS or Python auto-instrumentation), which automatically instruments every library it can find, including HTTP clients, databases, and web frameworks. See [unwanted spans in Langfuse](/faq/all/existing-otel-setup#unwanted-spans-in-langfuse).
- Another observability tool (Sentry, Datadog, Logfire) already set up the global TracerProvider, and Langfuse is attached to it too. See [using Langfuse with an existing OTEL setup](/faq/all/existing-otel-setup) or [with Sentry](/faq/all/existing-sentry-setup).
- Your deployment environment injects OTEL automatically (e.g. AWS Bedrock AgentCore with ADOT). See [AWS Bedrock AgentCore](/faq/all/existing-otel-setup#aws-bedrock-agentcore-adot).

For a deeper explanation of how the global TracerProvider works and how multiple tools interact, see [Using Langfuse with an existing OpenTelemetry setup](/faq/all/existing-otel-setup).

## How to fix it

### Upgrade to the latest SDKs (recommended)

The Langfuse Python SDK v4+ and JS/TS SDK v5+ apply a **default span filter** that automatically keeps only LLM-related spans and drops HTTP, database, and framework spans — no configuration needed. See [Filtering by Instrumentation Scope](/docs/observability/sdk/advanced-features#filtering-by-instrumentation-scope) for full details on what the default filter keeps and how to customize it.

```python
# Python v4+ — smart default filter, no configuration needed
from langfuse import Langfuse

langfuse = Langfuse()
```

```typescript
// JS/TS v5+ — smart default filter, no configuration needed
import { NodeSDK } from "@opentelemetry/sdk-node";
import { LangfuseSpanProcessor } from "@langfuse/otel";

const sdk = new NodeSDK({
  spanProcessors: [new LangfuseSpanProcessor()],
});

sdk.start();
```

### Customize filtering

If the default filter doesn't match your needs, you can customize which spans are exported. Each span carries an **instrumentation scope**, a label identifying which library created it.

To find the scope name of a span, click on any observation in the Langfuse UI and look for `metadata.scope.name`.

<LangTabs items={["Python SDK v4+", "JS/TS SDK v5+", "Python SDK v3", "JS/TS SDK v4"]}>

<Tab>

**Compose with the default filter** to add additional scopes:

```python
from langfuse import Langfuse
from langfuse.span_filter import is_default_export_span

langfuse = Langfuse(
    should_export_span=lambda span: (
        is_default_export_span(span)
        or (
            span.instrumentation_scope is not None
            and span.instrumentation_scope.name.startswith("my_framework")
        )
    )
)
```

Or **export everything** (not recommended):

```python
langfuse = Langfuse(should_export_span=lambda span: True)
```

</Tab>

<Tab>

**Compose with the default filter** to add additional scopes:

```typescript
import { isDefaultExportSpan, type ShouldExportSpan } from "@langfuse/otel";

const shouldExportSpan: ShouldExportSpan = ({ otelSpan }) =>
  isDefaultExportSpan(otelSpan) ||
  otelSpan.instrumentationScope.name.startsWith("my-framework");
```

Or **block specific scopes**:

```typescript
const blockedScopes = ["express", "http", "pg", "redis", "fastify"];

new LangfuseSpanProcessor({
  shouldExportSpan: ({ otelSpan }) =>
    !blockedScopes.includes(otelSpan.instrumentationScope.name),
});
```

</Tab>

<Tab>

**Block specific scopes** you don't want:

```python
from langfuse import Langfuse
from langfuse.span_filter import is_default_export_span

blocked = {
    # HTTP clients
    "opentelemetry.instrumentation.requests",
    "opentelemetry.instrumentation.httpx",

    # Web frameworks
    "opentelemetry.instrumentation.fastapi",
    "opentelemetry.instrumentation.starlette",
    "flask",
    "django",

    # Databases
    "sqlalchemy",
    "psycopg",
    "psycopg2",
}

langfuse = Langfuse(
    should_export_span=lambda span: (
        is_default_export_span(span)
        and (
            span.instrumentation_scope is None
            or span.instrumentation_scope.name not in blocked
        )
    )
)
```

The older `blocked_instrumentation_scopes` parameter still works, but is deprecated and planned for removal — prefer expressing deny rules in `should_export_span`.

</Tab>

<Tab>

**Block specific scopes** you don't want:

```typescript
import { NodeSDK } from "@opentelemetry/sdk-node";
import { LangfuseSpanProcessor } from "@langfuse/otel";

const blockedScopes = ["express", "http", "pg", "redis", "fastify"];

const sdk = new NodeSDK({
  spanProcessors: [
    new LangfuseSpanProcessor({
      shouldExportSpan: ({ otelSpan }) =>
        !blockedScopes.includes(otelSpan.instrumentationScope.name),
    }),
  ],
});

sdk.start();
```

</Tab>

</LangTabs>

For the full list of filtering options and helper functions, see the [SDK advanced features docs](/docs/observability/sdk/advanced-features#filtering-by-instrumentation-scope). The exact scope names depend on the libraries you use, so always check `metadata.scope.name` in the Langfuse UI to confirm which scopes to filter.

  If you filter out a parent span (e.g. a FastAPI request that wraps your LLM call), its children will appear as disconnected top-level traces. See [orphaned traces](/faq/all/existing-otel-setup#orphaned-traces) for workarounds.

---

Still seeing unexpected spans? Reach out to [support](/support).

<!-- agent-instructions -->

---

## Agent Instructions

This page is part of the [Langfuse](https://langfuse.com) documentation, published as plain Markdown for AI agents. Every page is available as Markdown by appending `.md` to its URL, or by sending an `Accept: text/markdown` header. This page: `https://langfuse.com/faq/all/unwanted-http-database-spans.md`.

### Querying these docs

If the answer is not on this page, query the documentation instead of guessing:

- **Semantic search** across all Langfuse docs, returning an answer with the relevant pages and excerpts. Ask a specific, self-contained question:

  ```bash
  curl -sG "https://langfuse.com/api/search-docs" --data-urlencode "query=How do I trace a LangGraph agent?"
  ```

- **Index of every page**: <https://langfuse.com/llms.txt>, with per-section indexes [llms-docs.txt](https://langfuse.com/llms-docs.txt), [llms-integrations.txt](https://langfuse.com/llms-integrations.txt), and [llms-self-hosting.txt](https://langfuse.com/llms-self-hosting.txt).

### Before writing Langfuse code

- **Install the [Langfuse Agent Skill](https://langfuse.com/docs/api-and-data-platform/features/agent-skill).** It encodes Langfuse's own best practices for instrumentation, prompt management, and evaluation, and materially improves results.
- **Read [What does a good trace look like?](https://langfuse.com/docs/observability/best-practices.md)** before instrumenting an application.
- **Verify endpoints, parameters, and response fields** against the [API reference](https://api.reference.langfuse.com) instead of inferring them from code examples.
- **Use the [Langfuse CLI](https://langfuse.com/docs/api-and-data-platform/features/cli)** (`npx langfuse-cli api <resource> <action>`) to read or write traces, prompts, datasets, and scores from the terminal.

Found an error in these docs? Please open an issue at <https://github.com/langfuse/langfuse-docs/issues>.