Monitor Supabase
Scrapes the Supabase Metrics API and receives the OTLP log drain, tags both with the project ref, and ships them to any OTLP/HTTP backend.
Supabase exposes two telemetry feeds: a Prometheus-format Metrics API with about 200 Postgres, host, and stack series, and log drains that push Postgres, Auth, Storage, and Edge Functions logs to an endpoint you choose. This flow takes both into one collector and ships them to the backend you already run, without a vendor-specific integration.
The prometheus/supabase receiver scrapes the Metrics API every 60 seconds. The otlp/supabase_drain receiver accepts the drain and checks a bearer token, so only Supabase can write to it. Both signals get the same supabase.project.ref, so you can go from a metric straight to the matching logs.
Set SUPABASE_PROJECT_REF, SUPABASE_HOST (your project-ref.supabase.co or custom domain), and SUPABASE_SECRET_KEY (an sb_secret_ key) for the scrape. Set SUPABASE_DRAIN_TOKEN to a random string and add it to the drain as an Authorization: Bearer header. Point OTLP_ENDPOINT and OTLP_AUTH_HEADER at your backend.
Use this flow
Open the config in Telflo and it becomes a working pipeline on the canvas: adapt what's specific to you, test it against recorded traffic, and push it to your fleet. Free account, no card.
Components
What's in it, and why
Scrapes the Supabase Metrics API once a minute over HTTPS, logging in as service_role with a secret key, and labels every series with the project ref.
Receives the project's log drain as OTLP over HTTP on :4318 and rejects any request that lacks the drain's bearer token.
Caps the collector at 80% of available memory and refuses data before the process runs out; first in both pipelines per its README.
Stamps supabase.project.ref on metrics and logs alike, and adds service.namespace and cloud.provider where they are missing, so both signals join on the same project.
Sends a batch once 8192 items arrive or 10 seconds pass, which cuts the number of export requests to the backend.
Ships both signals to any OTLP/HTTP backend with gzip and an auth header, retrying for up to five minutes behind a 100,000-item queue.
Serves the liveness endpoint on :13133 for the load balancer or orchestrator in front of the drain receiver.
Holds SUPABASE_DRAIN_TOKEN and checks it against the Authorization: Bearer header on every drain request.
Notes
Gotchas
- 1
The Metrics API is in beta and isn't available on self-hosted Supabase. Supabase warns that metric names and labels may change, so expect to revisit dashboards and alerts built on them.
- 2
Log drains are a paid add-on on the Pro, Team, and Enterprise plans: $60 a month per drain plus $0.20 per million events and egress, and the spend cap doesn't cover them.
- 3
Pick the OpenTelemetry (OTLP) drain type and give it the full URL ending in
/v1/logs, not the bare host. The drain only speakshttp/protobuf, so it has to reach the receiver's HTTP port, and turning on gzip cuts egress. - 4
The drain sends the bearer token on every request, so put TLS in front of port 4318 with a load balancer or a
tlsblock on the receiver. Over plain HTTP the token crosses the internet in the clear. - 5
resource/supabaseupserts a singleSUPABASE_PROJECT_REFonto everything the collector receives, so run one collector per project instead of pointing several projects' drains at the same one. - 6
The exporter's sending queue lives in memory, so a collector restart drops whatever is queued. Add the
file_storageextension and setsending_queue.storageif you can't afford to lose drain logs.
Sources and references (12)ShowHide
Everything consulted while researching and fact-checking this flow, including the README of every component it uses.
- supabase.com/docs/guides/telemetry/metrics
- supabase.com/docs/guides/telemetry/log-drains
- supabase.com/docs/guides/platform/manage-your-usage/log-drains
- github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.159.0/receiver/prometheusreceiver/README.md
- github.com/open-telemetry/opentelemetry-collector/blob/v0.159.0/receiver/otlpreceiver/README.md
- github.com/open-telemetry/opentelemetry-collector/blob/v0.159.0/processor/memorylimiterprocessor/README.md
- github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.159.0/processor/resourceprocessor/README.md
- github.com/open-telemetry/opentelemetry-collector/blob/v0.159.0/processor/batchprocessor/README.md
- github.com/open-telemetry/opentelemetry-collector/blob/v0.159.0/exporter/otlphttpexporter/README.md
- github.com/open-telemetry/opentelemetry-collector/blob/v0.159.0/exporter/exporterhelper/README.md
- github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.159.0/extension/healthcheckextension/README.md
- github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.159.0/extension/bearertokenauthextension/README.md
More flows
Related flows
Replace vendor agents on your VM fleet
Scrapes CPU, memory, load, disk, filesystem, and network metrics plus system and application logs on every VM.
Ship OTel data to ClickHouse
The ClickStack (HyperDX) ingestion collector as upstream ships it: parses JSON log bodies into attributes, infers severity from level fields or the body text, and routes browser session-replay events to their own ClickHouse table.
Collect per-node telemetry with a DaemonSet
Per-node DaemonSet that scrapes kubelet and host metrics, tails pod logs with the container parser and file_storage checkpoints, enriches everything with k8sattributes, and forwards to the in-cluster gateway.
Test it before your fleet runs it
Free account, no card. Open this flow in the editor, adapt it, and see what it does to real data before anything ships.