Supabase logs, metrics, and traces

Supabase exposes each signal differently: logs are pushed by a log drain, metrics are pulled from a Prometheus endpoint, and traces come from your own application, with Supabase propagating the trace context so its logs join your spans.

Signal	How it reaches Bronto	Supabase plan
Logs	Log drain posts OTLP directly to Bronto — no infrastructure	Pro, Team, or Enterprise
Metrics	OpenTelemetry Collector scrapes the Metrics API and forwards OTLP	All plans, including Free
Traces	Your application exports spans; Supabase propagates `trace_id` into its logs	All plans

Prerequisites

A Bronto API key with at least the Ingestion role (how to create one)
Your Supabase project reference — the 20-character string in Project Settings → General, or the subdomain of your project URL
For metrics: a Supabase secret API key (sb_secret_...) from Project Settings → API Keys, and an OpenTelemetry Collector

Send logs with a log drain

A log drain posts logs straight to Bronto’s OTLP endpoint. Nothing runs on your side.

Open Log Drains

In the Supabase dashboard, go to Project Settings → Log Drains and select Add drain.

Choose the OpenTelemetry destination

Select OpenTelemetry (OTLP) as the destination type.

Point it at Bronto

Fill in the fields below, then save the drain.

Field	Value
Endpoint	`https://ingestion.<REGION>.bronto.io/v1/logs`
Protocol	`http/protobuf`
Gzip	Enabled
Header	`x-bronto-api-key` = `<YOUR_API_KEY>`

Replace <REGION> with eu or us.

The drain covers Postgres, Auth, Storage, Realtime, PostgREST, API Gateway, and Edge Function logs. Supabase batches events and delivers on whichever comes first: 250 events or one second.

Send metrics with the OpenTelemetry Collector

Every Supabase project serves roughly 200 Postgres performance and health series in Prometheus format at:

https://<PROJECT_REF>.supabase.co/customer/v1/privileged/metrics

/etc/otel/config.yaml

receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: supabase
          scrape_interval: 60s
          scrape_timeout: 30s
          metrics_path: /customer/v1/privileged/metrics
          scheme: https
          basic_auth:
            username: service_role
            password: <YOUR_SUPABASE_SECRET_KEY>
          static_configs:
            - targets: ["<PROJECT_REF>.supabase.co:443"]

processors:
  batch:
  resource/supabase:
    attributes:
      - key: supabase.project_ref
        value: <PROJECT_REF>
        action: upsert

exporters:
  otlphttp/brontometrics:
    metrics_endpoint: https://ingestion.<REGION>.bronto.io/v1/metrics
    compression: gzip
    headers:
      x-bronto-api-key: <YOUR_API_KEY>

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [resource/supabase, batch]
      exporters: [otlphttp/brontometrics]

If your Collector already sends logs or traces, add this receiver and exporter to its metrics pipeline and leave the other pipelines alone. See Send metrics to Bronto.

The secret API key grants broad access to your project. Treat it as a credential: store it in a secret manager, pass it by environment variable, and rotate it periodically.

Send traces from your application

Supabase’s managed services do not emit their own spans, but its SDKs propagate W3C trace context on Supabase-bound requests. The resulting trace_id appears in API Gateway and Edge Function logs, so your application’s spans and Supabase’s logs land in the same trace — letting you go from a slow request straight to the Postgres statement behind it. Instrument your application with the OpenTelemetry SDK and point it at Bronto — see Ingest OpenTelemetry data into Bronto.

What you will see in Bronto

Metrics arrive as the supabase dataset in the .metrics collection — roughly 200 distinct series per project:

Area	Examples
Database	`pg_database_size_bytes`, query and index statistics, conflicts, recovery state
Connections	`connection_stats_connection_count`, `direct_connection_stats_connection_count`
Pooler	`pgbouncer_pools_client_active_connections`, `pgbouncer_pools_server_idle_connections`, `pgbouncer_pools_client_maxwait_seconds`
Latency	`db_sql_latency_milliseconds`
Replication	Realtime replication status and lag
Host	`node_cpu_seconds_total`, `node_filesystem_size_bytes`, disk IO, memory, network
Auth	`auth_users_user_count`

Logs arrive as separate sources for Postgres, Auth, Storage, Realtime, PostgREST, API Gateway, and Edge Functions — see Supabase’s logging reference for the fields each one carries — parsed on arrival so fields are searchable without further configuration.

Troubleshooting

Symptom	Cause
`401` or `403` scraping the Metrics API	The password is not a secret or `service_role` key. The username must be `service_role`.
`404` scraping the Metrics API	Wrong `<PROJECT_REF>`. Check Project Settings → General.
`401` from Bronto	The API key lacks the Ingestion role.
Log drain reports errors	The endpoint must include the `/v1/logs` path, and the protocol must be `http/protobuf`.
Metrics arrive with no project tag	The `resource/supabase` processor is missing from the `metrics` pipeline.
No Log Drains option in the dashboard	Log drains require Pro, Team, or Enterprise.

Overview

Ingest with agents

Ingest from AWS

Ingest from Azure

Ingest from CDN and edge

Ingest from apps and platforms

Ingest from infrastructure and databases

Ingest OpenTelemetry data

Supabase logs, metrics, and traces

Prerequisites

Send logs with a log drain

Send metrics with the OpenTelemetry Collector

Send traces from your application

What you will see in Bronto

Troubleshooting

​Prerequisites

​Send logs with a log drain

​Send metrics with the OpenTelemetry Collector

​Send traces from your application

​What you will see in Bronto

​Troubleshooting

Prerequisites

Send logs with a log drain

Send metrics with the OpenTelemetry Collector

Send traces from your application

What you will see in Bronto

Troubleshooting