Troubleshoot Supabase in n8n: 12 Fixes
Diagnose and fix the most common Supabase errors in n8n — auth, rate limits, schema drift, and more.
Key takeaways
- Most failures are auth, rate, or drift.
- Retry with backoff solves 90% of noise.
- Idempotency keys prevent duplicate writes.
- Log payloads or you'll debug blind.
Most Supabase failures in n8n fall into a small set of buckets. This guide covers each one, what causes it, and the exact fix.
Auth failures
Symptom: 401 or invalid credential. Cause: expired token, wrong scope, or IP restriction. Fix: re-authenticate and confirm the scope covers the endpoints you're hitting.
Rate limits
Symptom: 429. Fix: add a Wait node inside a Loop, or enable the Supabase node's built-in retry with backoff.
Schema drift
Symptom: fields missing or misnamed. Cause: Supabase shipped an API change. Fix: use optional-chaining in expressions and log payloads so you spot drift fast.
Timeouts and duplicates
Symptom: partial writes. Fix: idempotency key on every write, plus a dedupe node keyed off the Supabase record ID.
Frequently asked questions
- Where do n8n error logs live?
- Executions tab in the UI, or the Postgres executions_entity table.
- How do I test error paths?
- Force a failure in a sandbox workflow and confirm the alert lands.
- Should I retry indefinitely?
- No — cap retries and route to a manual review queue.
- What about partial success?
- Split into per-record sub-workflows so one bad row doesn't kill the batch.