Monitor Supabase in Elastic: dashboards, alert templates, SLO templates, and zero agents

Elastic speaks OpenTelemetry natively. Send traces, logs, and metrics over OTLP straight into Elasticsearch, no proprietary agents required. See how it fits together, try it for free in the cloud, or run it locally.

Your Supabase project is doing more than you think. Underneath the clean dashboard and the auto-generated APIs, there's a PostgreSQL database handling transactions, a connection pooler that manages competing clients, an Auth service for every login, a PostgREST layer turning HTTP into SQL, and a node underneath that you never touch. When something slows down, any one of them could be the cause.

The Elastic Supabase Integration handles Supabase monitoring for every one of them, with nothing to deploy. No agent and no collector. Metrics come from Supabase's Prometheus-compatible Metrics API, logs arrive through Supabase Log Drains, and both sit in Elasticsearch where you can query them together. Four dashboards, a full set of alert rules, and four SLO templates install once data arrives. Elastic is a listed metrics monitoring partner on Supabase's observability docs.

What Supabase monitoring covers, layer by layer

The Supabase Integration covers the full stack of what Supabase actually is: a database plus a connection pooler plus an auth service plus a REST API layer plus real-time subscriptions plus file storage, all running on a node you don't directly manage.

The integration collects two signal types: metrics scraped from Supabase's Prometheus-compatible Metrics API, and logs forwarded through Supabase Log Drains. But what's interesting is the depth of each; this isn't "CPU and error rate." It goes all the way from the node your project runs on down to individual PostgreSQL statements, connection pool wait times, and per-service request counts.

Infrastructure and node metrics cover the compute layer Supabase runs on: CPU utilisation, memory availability, disk I/O, filesystem usage, and network traffic. On Supabase's smaller compute tiers, CPU and disk I/O are the most commonly exhausted resources. Their exhaustion cascades quietly into slower queries and connection pool pressure before anything explicitly fails.

PostgreSQL internals go deep: database size, active connections versus the max_connections ceiling, transaction commit and rollback counts, cache hit ratios, WAL volume, replication lag, bgwriter activity, and statement-level statistics from pg_stat_statements. This is the data you need to understand whether slowdowns are a schema problem, a connection problem, or a capacity problem.

Connection pooling covers both Supavisor (Supabase's shared pooler) and PgBouncer (the dedicated pooler). Pool occupancy, idle connections, and client wait times are the signals that show you whether connection exhaustion is approaching before clients start getting refused.

Application services: Auth (GoTrue), PostgREST, and Realtime emits their own metrics. GoTrue tracks running status and authentication request rates. PostgREST exposes database pool availability and timeout counts. Realtime tracks active client subscriptions. These are the layers users actually interact with, and their health is distinct from PostgreSQL's health.

Logs from every Supabase service land in a single data stream (logs-supabase.otel-*), with a service filter on the dashboard to focus on any individual component. When a PostgREST error rate spikes, the logs tell you exactly what requests failed and why.

All metrics land in metrics-supabase.metrics.otel-* with their original Prometheus names preserved.

How to connect Supabase metrics and logs to Elastic

The integration has two setup paths that run in parallel: metrics and logs.

For metrics:

1. In Kibana, go to Management → Integrations → Supabase and install the Supabase integration.
2. From your Supabase project, copy the Project URL under Settings → API.
3. Copy your service_role key from the same page.

The integration uses those to authenticate against Supabase's Prometheus endpoint and scrape metrics on a schedule.

For logs, Elastic operates a managed endpoint that receives log drain payloads. In Kibana, go to Add data → More → Supabase and copy the Supabase logs endpoint URL. It follows this pattern:

https://<managed-endpoint>/inputs/supabase/_default_/v1/logs

1. Create an API key there.
2. Go to your Supabase project's Settings → Log Drains and create a drain.
3. Choose OpenTelemetry (OTLP) as the destination.
4. Set the endpoint URL.
5. Choose http/protobuf as the protocol.
6. Enable Gzip.
7. Add the header:

Authorization: ApiKey <your-key>

For the full setup walkthrough, refer to the Supabase (OpenTelemetry) Integration docs.

What ships with Supabase monitoring in Elastic

Once data is flowing, dashboards, alert rule templates, and SLO templates install automatically via the Supabase OpenTelemetry Assets package.

Four Supabase dashboards in Kibana

The Node & Infrastructure dashboard is where resource exhaustion shows up first. CPU saturation, memory pressure, disk I/O utilisation, filesystem usage, and network throughput – all at the node level. On smaller compute tiers, this dashboard often tells the story before PostgreSQL metrics do.

The Databases & PostgreSQL dashboard covers the database layer in depth: connection counts versus the max_connections limit, transaction throughput, cache hit ratios, WAL volume, replication lag, PgBouncer pool status, and bgwriter activity. This is where you diagnose whether a slowdown is a schema problem, a connection problem, or a capacity problem.

The Services & API dashboard covers the application layer: Auth (GoTrue) running status and request rates, PostgREST database pool availability and timeouts, Realtime subscription counts, and Go runtime metrics. A PostgREST pool timeout spike or a GoTrue outage shows up here before users start filing support tickets.

The Service Logs dashboard brings together log streams from every Supabase service with a service filter to focus on any single component. When an error rate spikes on the Services dashboard, this is where you read what actually happened.

Alert rule templates for Supabase failure modes

Pre-built alert rules ship with the Assets package, covering Supabase's specific failure modes in a way generic infrastructure alerts don't. They cover:

• Service availability – PostgreSQL, Auth (GoTrue), and PgBouncer each have dedicated rules, because each failure has a different blast radius. PostgreSQL down means everything fails. Auth down means no new logins. PgBouncer down means clients fall back to direct connections and can exhaust the connection budget within minutes.
• Connection budget exhaustion – the most common way a Supabase project fails. Once max_connections is hit, new clients are refused outright.
• Long running transactions – which hold locks, block vacuum, and pin WAL simultaneously.
• PostgreSQL deadlocks – any deadlock in the window is worth surfacing. These are application bugs, not capacity problems, and they show up as pg_stat_database_deadlocks_total increasing.
• Replication slot lag – building quietly toward disk exhaustion.
• Disk I/O saturation and memory pressure – infrastructure signals that precede failures at the database and service layer.
• PostgREST pool timeouts – each one a user visible 504 error.
• Metrics collection health – fires when the scraper itself starts failing, because a silent scraper means every other alert goes quiet.

SLO templates for Supabase

Four SLO templates ship with the Assets package.

Start monitoring your Supabase project

If you're on Supabase Pro, Team, or Enterprise and already using Elastic Cloud, both signal types are available to you today. The integration covers the full stack (infrastructure, database internals, application services, and logs), so you can start with whatever is most pressing and layer in the rest from there.

The integration is available on Elastic Cloud Serverless and Elastic Cloud Hosted. Head to Management → Integrations → Supabase in Kibana to get started, or follow the Supabase (OpenTelemetry) Integration docs.