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
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: jsonReplace:
YOUR_PROJECT_REFwith your Supabase project reference.YOUR_TABLEwith a table that is safe to query.YOUR_SUPABASE_ANON_KEYwith 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.
?select=id&limit=1Do 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.