Overview
The supabase Agent-based integration was missing Supavisor pooler metrics in its allowlist; (PR #23749) adds them.
The SaaS supabase_cloud tile integration has the same gap — and since its check code is not in this public repo, the fix needs to happen on the SaaS team's side.
What's missing
The Supabase customer Metrics API (https://<project-ref>.supabase.co/customer/v1/privileged/metrics) exposes ~24 supavisor_* metrics emitted by Supavisor's PromEx Tenant plugin. The current supabase_cloud integration ingests none of them — confirmed by inspecting supabase_cloud/metadata.csv in this repo (65 metrics, zero supavisor.* entries) and by querying search_datadog_metrics against a production project (zero supabase.cloud.supavisor.* series).
Why this matters
The most operationally important Supavisor metric is supavisor_connections_active — it counts client connections currently held by the pooler per tenant, and is the metric that backs the "Shared Pooler (Supavisor) Client Connections" graph in Supabase Studio's Observability section. It's also the right signal for alerting on pooler client-slot exhaustion, a common failure mode in serverless / Vercel Fluid Compute setups where pool sockets can leak across function terminations (see e.g. supabase/discussions#40671).
Customers using the supabase_cloud SaaS integration currently have no Datadog signal for this until the database starts rejecting connections with FATAL: Max client connections reached. The metric is sitting on the wire — the SaaS scraper just isn't picking it up.
Suggested action
Add supavisor_* mappings to the supabase_cloud SaaS scraper to mirror what PR #23749 adds to the Agent-based integration. The metric list, fixture, and proposed Datadog naming (supabase.cloud.supavisor.*) are in that PR; happy to provide a separate PR against supabase_cloud/metadata.csv to document the desired end state if helpful.
Related
Overview
The
supabaseAgent-based integration was missing Supavisor pooler metrics in its allowlist; (PR #23749) adds them.The SaaS
supabase_cloudtile integration has the same gap — and since its check code is not in this public repo, the fix needs to happen on the SaaS team's side.What's missing
The Supabase customer Metrics API (
https://<project-ref>.supabase.co/customer/v1/privileged/metrics) exposes ~24supavisor_*metrics emitted by Supavisor's PromEx Tenant plugin. The currentsupabase_cloudintegration ingests none of them — confirmed by inspectingsupabase_cloud/metadata.csvin this repo (65 metrics, zerosupavisor.*entries) and by queryingsearch_datadog_metricsagainst a production project (zerosupabase.cloud.supavisor.*series).Why this matters
The most operationally important Supavisor metric is
supavisor_connections_active— it counts client connections currently held by the pooler per tenant, and is the metric that backs the "Shared Pooler (Supavisor) Client Connections" graph in Supabase Studio's Observability section. It's also the right signal for alerting on pooler client-slot exhaustion, a common failure mode in serverless / Vercel Fluid Compute setups where pool sockets can leak across function terminations (see e.g. supabase/discussions#40671).Customers using the
supabase_cloudSaaS integration currently have no Datadog signal for this until the database starts rejecting connections withFATAL: Max client connections reached. The metric is sitting on the wire — the SaaS scraper just isn't picking it up.Suggested action
Add
supavisor_*mappings to thesupabase_cloudSaaS scraper to mirror what PR #23749 adds to the Agent-based integration. The metric list, fixture, and proposed Datadog naming (supabase.cloud.supavisor.*) are in that PR; happy to provide a separate PR againstsupabase_cloud/metadata.csvto document the desired end state if helpful.Related