Your coding agent can now query your Supabase logs, and our skill points it to the signals to watch. So it can check your project for error spikes, security issues, slow queries, and growing usage. You choose when it runs. 🤖 Here's how to set it up →

For each problem, your agent gives you the measured value and where to look. Set up an agent prompt →

been doing this on feednest for a while, my agents already had supabase hooked in and fixed a lot of slow queries. nice that it's built in now

does it flag rls misconfigs too or just perf stuff?

the slow query and the code that fires it finally end up in the same context. no more copying stack traces from the dashboard into the editor

Read-only checks are a good starting point. The next useful loop is finding → owner → resolution: carry an unresolved issue forward without presenting it as a new incident on every run. Otherwise a helpful daily check can turn into a very polite alarm clock.

Very nice.

I'd want the report to show the previous baseline next to each spike. “errors doubled” reads very differently when it's 2 to 4 versus 2,000 to 4,000.

slow queries is where I would point it first, one count(*) of mine went from 3,925ms to 4ms just by reading reltuples instead

Can this run with a read-only setup, so the agent only gets logs and advisors and nothing else?

having it check slow queries on its own schedule is the part i'd use. right now i only notice one when a page takes 6 seconds and i go digging in the dashboard

Sounds fantastic, gonna give it a try!

the logs finally get a reading buddy

Agents reading prod logs will catch more bugs than agents writing more code.

can you make a better safer read only mcp

The hard part isn't reading the logs, it's knowing what changed. A slow-query spike after a deploy and one after a newsletter look the same in logs. Give the agent the deploy and traffic timeline too, and alerts turn into an actual diagnosis.

the security check is the part i'd run first. does it flag tables with RLS turned off, or only what shows up in the logs?

great, now my AI can judge my 400ms query latency in real time

Please let repeat findings update one existing issue instead of opening a fresh one every run. An agent discovering the same slow query 40 times is a very enthusiastic new source of noise.

I have issue subscription monthly it is possible for yearly subscription

read_only=true covers the database. The report is still a write, a Linear issue in the blog's example, and it's built from logs whose request paths and user agents anyone on the internet can type.

without a baseline it just narrates the most recent error

The prompt is unusually disciplined, and I'd keep it exactly as it is: "never treat a failed or incomplete check as clear", "never invent a baseline, limit, forecast, or cause", and the report rule of at least 20 errors, at least 1%, and at least twice the preceding rate with a 100-response floor. One input is missing though, and it's the one your own docs hand to the human. The Health page says to run it on demand after a deployment. A human running it right after a deploy brings exactly one thing the agent can't get on its own - what changed. The monitor's declared inputs are all observed state: query_logs, execute_sql, get_advisors. Nothing in that list says the system was different an hour ago. So the report can say "server errors doubled in the last complete hour" and its next step is still "investigate the API" - the rate moved, but nothing says what moved with it. For a coding agent that input is already on disk: commit timestamps between the two windows, and your migration history. Passing those in as observed facts with timestamps doesn't touch your rule - "a deploy at 14:30 sits between the two windows" is an observation, "that deploy broke auth" stays a hypothesis. If the platform can expose deploy events through an API, that's better still, but the repo already has enough to start. One detail that would make the comparison honest: your windows are whole UTC hours and a deploy is not. So the first comparison after a change mixes pre-change and post-change traffic (it under-reports the effect), and the next comparison compares a clean hour against an hour that contains the change. When a change lands inside a window, the report should say so instead of silently averaging. And to answer @Atlantisxd's question: yes for misconfiguration - the Security prompt watches "RLS and privilege issues identified by advisors", and the skill's checklist enumerates the specific traps (views bypass RLS by default, UPDATE needs a SELECT policy, auth.role() is deprecated, TO authenticated alone is BOLA/IDOR, SECURITY DEFINER bypasses RLS). One asymmetry worth knowing: logs show failures, so they catch a policy that blocks too much. A policy that lets too much through produces no failures and never appears there - only the advisor sees it, before it leaks. Boundary: I haven't run this against a real project. I've read the prompts and the canonical detecting spec, so treat the change-timeline part as a proposal rather than a measurement.

Skill-guided agents work best when you pin the thresholds yourself. Practical tip: seed the skill with your P95 latency and 5xx budget for your region, so it flags regressions the same way your team would instead of chasing noisy log lines.

a useful step toward agents that can maintain the software they help build. Especially useful for solo builders who don't have a dedicated team watching infrastructure