studio / security · 01 — On-call surface

Built for Friday afternoons.

Four sub-tabs answer the four questions you ask when something looks off: who's blocking, what policies attach, who has too much access, and what every grantee can do.

4 sub-tabscancel + kill PIDsRLS deny-all warningspermission matrixv0.2 · shipped

02 — Locks

See who's blocking whom.

The lock graph reads pg_locks + pg_stat_activity together. Blockers and waiters are highlighted, the chain is visible at a glance, and the action buttons live next to each PID.

blocking chain3 sessions · 1 blocker

Blocker

A session holding a lock that someone else wants. Highlighted in red.

Waiter

A session whose query is queued behind a blocker. Highlighted in amber.

Cancel · kill

Cancel sends pg_cancel_backend. Kill sends pg_terminate_backend. Both are one click.

03 — Row-level security

Deny-all is the failure case nobody catches.

RLS enabled with no policies = nobody can read the table (except the owner). Studio flags it. So is FORCED RLS, which applies even to the owner. The combinations that don't match what you intended are surfaced.

RLS state · per table1 flagged

table	RLS	policies	status
users	ON	3	OK
orders	ON	2	OK
audit_log	ON	0	DENY-ALL
products	off	0	RLS OFF
sessions	ON	4	FORCED

audit_log has RLS enabled but zero policies. Effectively deny-all to anyone but the owner. Either add a policy or disable RLS — the current state usually means a migration that didn't finish.

04 — Roles + permissions

Who can do what, at a glance.

The permission matrix is a single grid: grantees on rows, tables on columns, privilege chips in the cells. Roles with bypass-rls or superuser are flagged separately — those are the ones to audit first.