Reading Supabase Logs: The Five Queries That Catch 80% of Production Issues

The Supabase log explorer is a queryable interface over every request your project handles — Postgres queries, Auth events, Edge Function invocations, Storage requests, Realtime connections. Most teams ignore it until something breaks, then can’t find what they need. Here are the five queries we run regularly across the FH client book that catch the majority of production issues before customers report them.

#Where the log explorer lives

Supabase dashboard → Logs. The UI is split by source: Postgres, Auth, Storage, Edge Functions, Realtime. Each source has a SQL-like query language (Logflare under the hood). Queries can be saved and re-run. We have a saved-query collection across the FH project covering these five.

#Query 1: slow Postgres queries

Anything taking more than 500ms is a problem. Anything taking more than 2s is a fire. Find them before they cascade.

-- Logs explorer: postgres_logs source
select
  timestamp,
  parsed.query,
  parsed.duration_ms
from postgres_logs
where parsed.duration_ms > 500
order by parsed.duration_ms desc
limit 50;

Look at the queries that come up most often. Add an index if a sequential scan is showing up. Rewrite if a join is materializing too much data.

#Query 2: RLS denials

RLS denials don’t throw application errors — they just return zero rows. The query succeeded, the result was empty. From the application’s perspective, “no data” and “data the user can’t see” look identical. The Postgres logs show the difference.

select
  timestamp,
  parsed.query,
  parsed.user_name
from postgres_logs
where parsed.query ilike '%rls%'
   or parsed.error_severity = 'ERROR'
order by timestamp desc;

#Query 3: failed Auth events

Magic-link emails that don’t arrive. Sign-in attempts that fail. Tokens that don’t refresh. The Auth logs surface them with structured fields per event type.

select
  timestamp,
  event_message,
  metadata.path,
  metadata.status
from auth_logs
where metadata.status >= 400
order by timestamp desc
limit 100;

#Query 4: Edge Function errors

Functions can fail silently if the caller doesn’t check the response. The function logs catch the failure even when the caller doesn’t.

select
  timestamp,
  event_message,
  metadata.function_name,
  metadata.execution_time_ms
from function_logs
where metadata.level = 'error'
order by timestamp desc
limit 50;

#Query 5: Storage rate-limit warnings

Bandwidth spikes from hot images. 4xx errors on uploads. RLS denials on private bucket access.

select
  timestamp,
  event_message,
  metadata.bucket,
  metadata.path
from storage_logs
where metadata.status_code >= 400
order by timestamp desc
limit 50;

#Building a weekly digest

We have an Edge Function that runs every Monday morning, executes these five queries via the logs API, summarizes the results, and emails the FH ops inbox. Most weeks the email says “nothing to see here.” The week something’s wrong, we know before the client does.

#Pipe logs to a real observability platform

The Supabase logs UI is fine for ad-hoc triage. For real ops — alerts, long retention, cross-source queries — pipe to Better Stack, Axiom, or Datadog. Supabase supports log drains on the Pro tier. We use Better Stack across the client book; the alerting catches issues 24/7 without anyone watching the dashboard.

#What to alert on

• Any query slower than 5s. Always indicates a missing index or runaway scan.
• More than 10 RLS denials in 5 minutes from the same user. Either a bug or an attack.
• Any Edge Function failing more than 5% of invocations. The function is broken or its caller is.
• Auth failure rate above 5% sustained for 10 minutes. Magic-link emails are bouncing or the auth service is degraded.
• Storage 4xx rate above 1%. A bucket policy is wrong or a hot image is being deep-linked from somewhere unexpected.

#Retention

Supabase Pro retains logs for 7 days. Anything longer needs the log drain to an external destination. For most SMB engagements 7 days is fine — by the time a problem persists past that, someone’s noticed. For incident post-mortems and trend analysis we keep 90 days in Better Stack.

#How this lands across FH client work

We have a weekly logs check on the FH ops Monday morning. Five queries, ten minutes, all client tenants covered. The cost of running the check is zero. The cost of not running it is whatever the next incident costs you — and incidents that surface from logs instead of customer complaints are dramatically cheaper to fix. Schedule a consultation if you want this set up on your project — it’s a one-day engagement that ships a saved query collection and a weekly digest.