Which alerting signals should a Supabase project route to an external sink before dashboard notifications become noise?

Our team runs a production Supabase project and wants alerting that is genuinely actionable. The platform exposes several distinct signal sources: query performance data built on pg_stat_statements, Auth audit events, connection pool saturation, and usage metrics for compute, bandwidth, and database size. Dashboard notifications cover some of this, while log drains and webhooks let us route events into an external observability stack with thresholds, grouping, and deduplication.

The tension is where the alerting logic should live. Keeping everything in Supabase-native notifications is simple but offers limited control over severity tiers and noise reduction. Pushing all logs to an external sink first risks shifting the noise—and the cost—rather than solving it, especially if filters are not defined up front. Plan tier also constrains which log-drain and notification options are available, so the answer may not be portable across projects.

Which signal categories (slow-query outliers, failed-login spikes, quota thresholds) justify external routing versus in-dashboard alerts, and is there a documented best practice for this split, or is it an unresolved decision each team must make based on tier and workload?