Log Drains

Log drains send all logs of the Supabase stack to one or more desired destinations. It is only available for customers on Pro, Team and Enterprise Plans. Log drains are available in the dashboard under Project Settings > Log Drains.

What you can do with log drains#

• Route Supabase logs (Postgres, Auth, Storage, Edge Functions, and more) to any observability platform.
• Combine Supabase logs with application-level traces — see Tracing with the JS SDK to extend your traces into Supabase.
• Archive logs to S3 for long-term retention and compliance.
• Build alerts and dashboards on top of Supabase log data in your preferred vendor.

HTTP destinations receive logs as batched POST requests with a maximum of 250 events or 1-second intervals, whichever comes first.

Custom endpoint#

Logs are delivered as a JSON array via HTTP POST. Both HTTP/1 and HTTP/2 are supported. Custom headers can be added to every request for authentication or routing.

Required configuration:

• URL — your endpoint URL (http:// or https://)
• HTTP Version — HTTP/1 or HTTP/2
• Gzip — enable to compress the payload before sending
• Headers — optional key/value pairs added to every request

OpenTelemetry (OTLP)#

Logs are sent to any OTLP-compatible endpoint using the OpenTelemetry Protocol over HTTP with Protocol Buffers encoding, following the OpenTelemetry Logs specification.

Required configuration:

• Endpoint — full URL of your OTLP HTTP endpoint (typically ends in /v1/logs)
• Protocol — http/protobuf (the only supported protocol)
• Gzip — enable to reduce bandwidth (recommended)
• Headers — optional authentication headers

Compatible platforms include OpenTelemetry Collector, Grafana Cloud, New Relic, Honeycomb, Datadog (OTLP ingestion), Elastic, and any other OTLP-compatible observability tool.

Datadog#

Logs are batched and sent to Datadog with Gzip compression. Each event's log source is mapped to the service field, and the source is set to Supabase. The payload message is a JSON string of the raw log event, prefixed with the event timestamp.

Required configuration:

• API Key — from Datadog Organization Settings
• Region — the Datadog site your account uses (US1, US3, US5, EU, AP1, AP2, US1-FED)

Steps:

1. Generate an API key in the Datadog dashboard.
2. Create the drain in Project Settings > Log Drains.
3. Watch incoming events on the Datadog Logs page.

Loki#

Logs are formatted and sent to the Loki HTTP push API. The log source and product name are used as stream labels. The event_message and timestamp fields are dropped from events to avoid duplicate data. Events are batched with a maximum of 250 events per request.

Required configuration:

• URL — your Loki push endpoint (e.g. https://my-logs.grafana.net/loki/api/v1/push)
• Username — optional, required for Grafana Cloud and other authenticated Loki instances
• Password — optional, required for Grafana Cloud and other authenticated Loki instances
• Headers — optional additional headers

See the official Loki HTTP API documentation for more details on the push API format.

Amazon S3#

Logs are written as batched files to an existing S3 bucket that you own.

Required configuration:

• S3 Bucket — name of an existing S3 bucket
• Region — AWS region where the bucket is located
• Access Key ID — used for authentication
• Secret Access Key — used for authentication
• Batch Timeout (ms) — maximum wait before flushing a batch (recommended: 2000–5000ms)

Sentry#

Logs are sent to Sentry's Logging product. All log event fields are attached as Sentry log attributes, which can be used for filtering and grouping. There are no cardinality limits on the number of attributes.

Required configuration:

• DSN — your Sentry project DSN in the format {PROTOCOL}://{PUBLIC_KEY}@{HOST}/{PROJECT_ID}

Steps:

1. Get your DSN from Sentry project settings.
2. Create the drain in Project Settings > Log Drains.
3. Watch incoming logs on the Sentry Logs page.

Axiom#

Logs are sent to an Axiom dataset as JSON, with the timestamp adjusted for Axiom's ingestion format.

Required configuration:

• Dataset Name — name of the target dataset in Axiom
• API Token — an Axiom API token with ingest permissions on the dataset

Steps:

1. Create a dataset in Axiom Console under Datasets.
2. Generate an API token with ingest access (see Axiom token docs).
3. Create the drain in Project Settings > Log Drains.
4. Watch incoming events in the Axiom Console Stream panel.

Last9#

Logs are sent to Last9 using its OpenTelemetry-native ingestion endpoint. Credentials are obtained from the Last9 OTEL integration panel.

Required configuration:

• Region — your Last9 cluster region (US West 1 or AP South 1)
• Username — from the Last9 OTEL integration panel
• Password — from the Last9 OTEL integration panel

Steps:

1. In the Last9 dashboard, open the OTEL integration panel and note your region, username, and password.
2. Create the drain in Project Settings > Log Drains.

Syslog#

Logs are forwarded to a remote Syslog receiver using TCP or TLS, adhering to RFC 5424.

Required configuration:

• Host — hostname or IP address of the Syslog receiver
• Port — port of the Syslog receiver (0–65535)
• TLS — enable to connect via SSL/TLS instead of plain TCP

Optional configuration:

• Structured Data — static RFC 5424 structured data included in every log frame (e.g. [exampleSDID@32473 iut="3"])
• Cipher Key — base64-encoded 32-byte key for AES-256-GCM encryption of the log body

TLS-only options:

• CA Certificate — PEM-encoded CA certificate for server verification (falls back to the system CA bundle if omitted)
• Client Certificate — PEM-encoded client certificate for mutual TLS (mTLS)
• Client Key — PEM-encoded client private key (required when a client certificate is provided)

Additional resources#

• Log Drains pricing breakdown — cost per drain, per million events, and egress charges.
• Metrics API — export Postgres performance metrics alongside your logs.
• Tracing with the JS SDK — instrument your application and combine traces with Supabase logs.