Supabase Killed Its logs.all Endpoint on September 23. If Your Monitoring Script Still Calls It, It's Already Broken.
Two days ago, Supabase's Management API stopped answering calls to logs.all. According to Supabase's own changelog, the endpoint was announced for removal on July 23, 2026, and it actually came down on September 23. If you built a custom status page, an alerting script, or a homegrown dashboard against that endpoint at any point in the last couple of years, and you didn't see the July announcement, it's broken right now and probably hasn't told you.
That's the part of this story worth writing about. Not the deprecation itself, deprecations happen constantly and most of them don't matter. What matters is the specific shape of who gets hurt by this one: solo devs who built something small and useful against an API two years ago, moved on to other things, and never subscribed to a changelog RSS feed for a tool they consider "just infrastructure."
What actually changed
The logs.all endpoint was part of Supabase's Management API, used to pull aggregated log data across a project. Supabase replaced it with a ClickHouse-backed logs endpoint. The new endpoint doesn't accept the old query parameters, it accepts ClickHouse SQL. That's not a drop-in replacement, it's a different query language sitting behind a different endpoint path, which means any script built against the old shape needs an actual rewrite, not just a URL change.
This is a Management API endpoint specifically, not the Supabase client library you use in application code. If your app talks to Supabase through @supabase/supabase-js for auth, database queries, or storage, this doesn't touch you. It only bites if you or a past version of you wrote something that calls Supabase's Management API directly to pull logs, which is a smaller but real population: people building custom observability, internal status pages, or Slack-alert-on-error scripts.
Who actually gets hit
I'd bet the people affected fall into two groups. First: anyone who followed an old blog post or Stack Overflow answer showing how to pull Supabase logs into a custom dashboard, copy-pasted it into a cron job two years ago, and hasn't touched it since. Second: anyone running a status page or uptime script that quietly polls logs.all as part of a broader health check, where the failure mode isn't an obvious crash, it's a script that starts silently returning errors or empty data that nobody's watching closely enough to notice for weeks.
That second failure mode is the genuinely dangerous one. A hard crash gets noticed fast. A monitoring script that degrades quietly is the kind of thing that gets discovered when a customer says "hey, is anything wrong? I've been getting errors," and you go looking at your dashboard and realize it's been broken since the 23rd.
The five-minute check
Search your own codebase and any cron jobs, GitHub Actions workflows, or serverless functions for the literal string logs.all or for calls to a URL pattern like /v1/projects/{ref}/analytics/endpoints/logs.all. If nothing turns up, you're fine and this whole post doesn't apply to you. If something does turn up, you now know exactly what to fix instead of guessing why your dashboard went quiet.
The actual fix
The replacement logs endpoint takes ClickHouse SQL instead of whatever query shape logs.all used. That's a genuinely different thing to write, not a syntax tweak, so budget more than five minutes for the fix itself even though the diagnosis takes five minutes. Supabase's own changelog and docs are the source of truth for the new query format; I'm not going to pretend I can hand you a working ClickHouse query for your specific log shape in a blog post, because it depends entirely on what you were pulling and why.
What I will say: if you're rewriting this anyway, this is a good moment to ask whether you still need a custom logs script at all, or whether Supabase's own dashboard, or a proper observability tool, now covers what you built that script to do two years ago because the alternative didn't exist yet.
The honest take
Breaking changes to platform APIs are a normal cost of building on managed infrastructure, and Supabase gave two months of notice, which is reasonable by industry standards. The failure here isn't really Supabase's; it's the gap between "we announced this in the changelog" and "the people affected actually saw it," which is a gap every platform has and every solo dev underestimates until it's their script that goes quiet.
Where I could be wrong, or where this matters less than I'm framing it: if you're one of the many Supabase users who never touched the Management API directly and only use the client library, this changes nothing for you, and the actual blast radius here is probably a few hundred scripts across the entire Supabase user base, not a crisis. I'm writing this because the failure mode (silent, not loud) is worth a five-minute check even for people who are 90% sure they're unaffected.
What I'd actually do
Grep your codebase for logs.all right now, today, while you're thinking about it. Then, separately, go subscribe to whatever changelog or status feed your two or three most load-bearing pieces of infrastructure publish. A five-minute check today beats a customer finding your broken dashboard next week.
Author
Lukas
@lukcombinator