Set up a monitor and alert from a Supabase log drain
Pipe your Supabase infrastructure logs into Sentry so you can filter, monitor, and alert on database connections, edge function errors, and unusual log patterns without watching the Supabase dashboard.
Before you start
Accounts & access
- Sentry account with permissions to create projects
- Supabase project with access to the Logs / Observability settings
Knowledge
- Basic familiarity with the Sentry UI (projects, issues, alerts)
- Understanding of what Supabase logs contain (database events, edge function logs, API gateway logs)
1 Create a dedicated Sentry project for the log drain
Go to Settings > Projects and create a new project. Keep it separate from your application's Sentry project. The log drain sends all Supabase infrastructure logs (database, edge functions, API gateway, auth), and mixing them with your app errors makes both harder to triage. Name it something like supabase-logs so it's easy to identify.
2 Copy the DSN from your new project
Open your new project's settings in Sentry and find the DSN (Data Source Name) under Client Keys. Copy it. You'll paste it into Supabase in the next step. The DSN tells Supabase where to send the logs.
Supabase log drain setup docs 3 Configure the log drain in Supabase
In your Supabase dashboard, navigate to Project Settings > Integrations (or Observability > Log Drains depending on your Supabase version). Add a new log drain destination, select Sentry, and paste the DSN you copied. Save the configuration. Supabase will start forwarding all log events to your Sentry project. There's no filtering at the source, so everything comes through.
Supabase log drain setup docs
4 Verify logs are flowing in the Logs Explorer
Open Explore > Logs in Sentry and select your new log drain project from the project dropdown. You should see log entries appearing within a minute or two. If nothing shows up, double-check the DSN in Supabase and make sure the project is selected in the Sentry UI.
Sentry Logs Explorer docs
5 Filter logs by severity and message
Supabase sends all log levels (debug, info, warning, error, and fatal) so the first thing you'll want to do is filter out the noise. Use the search bar to narrow down to what matters.
severity:errorto see only errorsmessage:connection receivedto monitor healthy database connectionsseverity:!info message:connection receivedto combine filters and exclude routine info-level logs
6 Create a monitor from your log query
Once you have a filtered log query that represents a signal you care about (like message:connection received), click Save as Monitor. Configure the monitor conditions:
- Metric — count (number of matching log events)
- Time window — e.g. 1 hour
- Threshold — e.g. alert if the count drops below 10 per hour, which could indicate your database is losing connections
- Dynamic alerting — use anomaly detection instead of a static threshold if you don't know your baseline yet. Sentry's ML will learn the normal pattern and alert on deviations
7 Attach an alert rule with notification channels
Navigate to Alerts and create a new alert rule linked to your monitor. Configure the trigger conditions and who gets notified:
- Trigger — when the monitor's threshold is breached (e.g. a new issue is created)
- Notify — send to a team, Slack channel, email, or integrations like Linear and GitHub
- Resolve — optionally notify when things return to normal so the team knows the incident is over
That's it.
Your infrastructure talks back now.
When Supabase database connections drop or edge functions start failing, your team gets notified through the channels they already use, before users notice.
- Created a dedicated Sentry project for Supabase infrastructure logs
- Connected a Supabase log drain to Sentry using a DSN
- Filtered logs by severity and message in the Logs Explorer
- Built a monitor that tracks log volume over a rolling time window
- Configured alert rules to notify your team via email or Slack when thresholds are breached
Pro tips
- 💡 Use a dedicated Sentry project for the log drain. Mixing infrastructure logs with application errors makes both harder to triage and can skew your issue counts.
- 💡 Start with dynamic alerting (anomaly detection) if you don't know your baseline. Once you understand the normal pattern, switch to static thresholds for more predictable behavior.
- 💡 Create separate monitors for different signal types (one for database connections, one for edge function errors, one for auth failures) so you can tune thresholds independently.
- 💡 Use Sentry's Logs Explorer to prototype your filter query before saving it as a monitor. Iterate on the query until it reliably surfaces the signal you care about.
Common pitfalls
- ⚠️ Supabase log drains send all log levels with no source-side filtering. If you skip the severity filter in Sentry, you'll monitor noise and get false alerts.
- ⚠️ Don't set thresholds too tight on a new monitor. You'll get paged for normal variance. Start loose and tighten as you learn the baseline.
- ⚠️ Don't forget to select the log drain project in the Sentry UI. If you're looking at the wrong project, you won't see any Supabase logs.
- ⚠️ Avoid hardcoding organization slugs in Sentry URLs when sharing with teammates. Use the orgredirect pattern or navigate through the UI.
Frequently asked questions
What's next?
Fix it, don't observe it.
Get started with the only application monitoring platform that empowers developers to fix application problems without compromising on velocity.