Stack Pulse Docs
StackPulse

StackPulse Docs

Supabase REST Check

Configure a low-impact Supabase REST API check with scoped headers and a tiny query.

You can use Supabase REST to verify that a project is reachable and that a table can be read under your Row Level Security policy.

Recommended check

text
Name: Supabase REST API
Method: GET
URL: https://YOUR_PROJECT_REF.supabase.co/rest/v1/YOUR_TABLE?select=id&limit=1
Headers:
  apikey: YOUR_SUPABASE_ANON_KEY
  Authorization: Bearer YOUR_SUPABASE_ANON_KEY
Expected status: 200
Expected response type: json

Replace:

  • YOUR_PROJECT_REF with your Supabase project reference.
  • YOUR_TABLE with a table that is safe to query.
  • YOUR_SUPABASE_ANON_KEY with the anon key when possible.

Key choice

Use the anon key when possible.

Avoid service role keys unless absolutely necessary. A service role key bypasses Row Level Security and should not be used for a routine external health check.

RLS requirements

The table and query must be readable under RLS for the key you use.

If RLS blocks the query, Supabase may return an error even though the project is healthy. In that case, either adjust a narrow read policy for the monitored table or use your own health endpoint.

Keep the query tiny

Use limit=1 and select only a small stable field.

text
?select=id&limit=1

Do not scan large tables or request wide rows. The goal is availability monitoring, not reporting.

Alternative health endpoint

For stronger control, create your own /health endpoint in your API that checks Supabase server-side and returns a small JSON response.

That approach keeps provider keys out of the external check and lets you define exactly what healthy means.