A Supabase monitoring dashboard that also reads your own tables
Service health, disk usage, and security advisories — plus any number your own SQL can answer.
Get early access to the Supabase integration
dev-views is in active development. Join the waitlist and we will note your interest in Supabase.
A Supabase project has two kinds of state, and only one of them is on the Supabase dashboard. The platform state — is Postgres healthy, is the disk filling, has the security advisor flagged a table without row-level security — is there. The product state, the thing you actually care about, is inside your own tables: how many people signed up today, how many orders came in, how long the queue is.
dev-views reads both. Twenty-six built-in readings come from the Supabase Management API and cover service health, disk, advisories, and platform inventory. Alongside them you can define up to five metrics of your own with plain SQL, so the count that matters to your product sits on the same dashboard as the deploy that shipped it and the revenue it produced.
What dev-views reads from Supabase
26 readings, computed from the Supabase API. There are no defaults — you choose which become tiles and in what order, because guessing which of 26 matters to you would be wrong for most people.
Services healthy
How many of the six services — Postgres, Auth, PostgREST, Realtime, Storage, and the connection pooler — report healthy, with each one available individually.
Disk used, percent
The share of the database disk in use, next to the absolute figures. This is the reading that predicts the outage rather than reporting it.
Read-only mode
Whether the database has been forced read-only — almost always because the disk filled. Writes are already failing by the time you notice any other way.
Security errors
Findings from Supabase's security advisor at error level, such as a table exposed without row-level security. These are the ones to fix first.
Custom metrics
Up to five readings you define with your own SQL — a waitlist count, registered users, orders today — rendered as tiles beside everything else.
The full list
- Project status
- Database health
- Auth health
- REST health
- Realtime health
- Storage health
- Pooler health
- Services healthy
- Read-only mode
- Disk used
- Disk used, percent
- Disk free
- Postgres version
- Release channel
- Migrations
- Latest migration
- Security advisories
- Security errors
- Performance advisories
- Edge functions
- Storage buckets
- Public buckets
- Preview branches
- Region
- Created
- Organization
How the connection works
- 01Create an access token in Supabase under Account → Access Tokens, with an expiry date.
- 02Paste it into dev-views. It is verified against the Management API before anything is stored.
- 03Pick the project to watch from those the token can see.
- 04Choose your tiles, and optionally add custom metrics: a label and a SQL query that returns a single value.
- Credential
- A access token (sbp_…), created under Account → Access Tokens.
- Watches
- One project, chosen after connecting.
- Refresh
- Every 60 seconds, cached per user so browsing does not re-spend your API budget. A manual refresh forces a read immediately.
- Storage
- Encrypted with AES-256-GCM before it is stored. The encryption key lives in the environment, never in the database, and the credential is never sent back to the browser.
A Supabase access token has full access to your account, with no way to narrow it to a single project. dev-views only reads, and the token is encrypted at rest with AES-256-GCM, but this is the least scopable credential of the seven — treat it as you would your password and give it an expiry date.
What your dashboard shows
- Six services reported individually rather than as one aggregate light, so a Realtime problem is not hidden behind a healthy Postgres.
- Disk usage as both an absolute figure and a percentage, because on a small plan the percentage is what tells you how long you have.
- Security and performance advisories as counts you can act on — a table without row-level security is a finding, not a footnote.
- Your own SQL metrics as first-class tiles, indistinguishable from the built-in ones once they are on the board.
Who this is for
- Solo developers running a production Supabase project who want to see a filling disk before it forces the database read-only.
- Anyone who has shipped a table without row-level security and would rather find out from a dashboard than from a stranger.
- Developers who want a live product number — signups today, orders this week — without building an admin panel for it.
Supabase questions
Which Supabase metrics does dev-views track?
Twenty-six built-in readings for one project: health for Postgres, Auth, PostgREST, Realtime, Storage, and the pooler, plus a healthy-services count, project status, and whether the database has been forced read-only; database facts including disk used, free, and percentage, Postgres version, release channel, and migration history; counts from the security and performance advisors; platform inventory covering edge functions, storage buckets, public buckets, and preview branches; and project facts such as region, organization, and creation date.
Can I add my own metrics with SQL?
Yes, and it is the reason this integration exists in the shape it does. You can define up to five custom metrics, each a label and a SQL query returning a single value — a waitlist count, active users, orders today. The built-in readings describe the platform; custom ones describe the product running on it, which no fixed catalog can cover. The limit of five keeps the request budget comfortable: ten platform requests already go out per refresh against a 120-per-minute limit.
Can I give dev-views a token scoped to one project?
Supabase does not offer that. A personal access token carries full account privileges and can read and change every project on the account — there is no per-project variant. dev-views is transparent about this on the connect screen rather than glossing it: the token is encrypted with AES-256-GCM before storage, the encryption key lives in the environment and never in the database, and no code path writes to the Management API. Setting an expiry date is the strongest additional control available to you.
What are security advisories?
Supabase runs an advisor over your project and reports findings — a table exposed without row-level security, a function with a mutable search path, a missing index hurting a common query. dev-views surfaces the total and, separately, the count at error level, because those are the ones worth interrupting your day for. Performance findings are tracked as their own reading.
How often does it refresh?
Every 60 seconds, cached per user and project. Your saved settings form part of the cache key, so editing a custom metric shows the new reading immediately rather than after the window expires.
Works alongside
dev-views is most useful when more than one service is on the board. These are the ones people connect next to Supabase.
Watch Supabase alongside the rest of your stack
One read-only surface for every service you run. Join the waitlist for early access.