Fix: Supabase local logs "Backend error" (and old 502s)

TL;DR#

Studio's Logs page is where a local Supabase project is meant to show you its own API Gateway, Postgres and Auth traffic — docker logs on the relevant container still works directly when it does not. At least three times now — May 2024, July 2025, and in October 2026 — a bug in the local analytics pipeline behind Studio's Logs page has taken every tab down at once; your error is most likely one of the three below. Right now (October 2026), the cause is Logflare 1.52.0 casting the @project query parameter to jsonb on the Postgres backend, so every logs query fails. Update to Supabase CLI 2.122.0, which pins the fix, or — without upgrading — write 1.50.15 into supabase/.temp/logflare-version yourself.

Error fetching logs
Backend error! Retry your query. Please contact support if this continues.

Or, on an older CLI/Logflare pairing, a 502 on the Logs page's own request (not your API), or this line in the supabase_analytics container's own logs:

(Postgrex.Error) ERROR 42703 (undefined_column) column "body" does not exist

Why API Gateway, Postgres and Auth logs break together#

supabase start enables analytics by default. Reproduced here on 25 October 2026: a fresh supabase init on CLI 2.122.0 (confirmed with npx supabase@latest --version, which prints 2.122.0) writes [analytics] enabled = true with backend = "postgres" into config.toml without you asking for it. That section starts Logflare, a BigQuery-style log query engine, pointed at a postgres backend instead of real BigQuery. Every tab in Studio's Logs page — API Gateway/Edge, Postgres, Auth, Functions — sends Logflare the same kind of query, and Logflare translates it into SQL that runs against _analytics.log_events_* tables inside your local Postgres container. That one translation layer is why supabase/supabase#26785 was filed under one title, "API Gateway and postgresql logging not working for local development", rather than as two separate bugs: they are the same query engine hitting two different tables, so one bug in that layer breaks both reports simultaneously, and now a third (Auth) as well.

May 2024 (supabase/supabase#26785): a Studio update started querying a body column that the local _analytics.log_events_* tables did not have, so every Logs tab failed: docker logs on the analytics container showed ERROR 42703 (undefined_column) column "body" does not exist, while Studio's own Logs page showed a 502 for that same request. The CLI team shipped an immediate relief by reverting the Studio image pin (supabase/cli#2332, merged 28 May 2024, "Studio update broke postgres logs page"), then fixed the query itself (supabase/supabase#27861, "fix logs query in local", merged 9 July 2024). Maintainer encima confirmed it working end to end on CLI 1.187.8 (comment) before closing the issue on 29 July 2024.

July 2025 (supabase/cli#3894): a different failure mode on CLI 2.31.8 — the _analytics schema and its log tables were never created at all on a fresh supabase start, so the Logflare container (up and running, not crashed) logged the same column "body" does not exist plus operator does not exist: jsonb ~~ unknown. No maintainer diagnosis appears on that thread. One commenter, twhittock, says reverting to CLI 2.29.0 (and removing the db.network_restrictions block from config.toml) fixed it for them; the reporter, whitfa99, closed the issue a month later saying it was "resolved… now using 2.34.3" — two different fixes, on a thread with no explanation of why either worked.

October 2026 (supabase/cli#7155, filed 14 October by a reporter on CLI 2.120.0): Logflare 1.52.0 changed how it casts query parameters — @project now gets cast to jsonb when translated for the Postgres backend, so every logs query fails with invalid input syntax for type json. Maintainer avallete root-caused it the next morning and filed it upstream as Logflare/logflare#4158, plus a second, longer-standing bug where IFNULL() (BigQuery) is never translated to COALESCE() (Postgres), tracked as Logflare/logflare#4159 — that one breaks the per-minute logs chart on every Logflare version, not just this one.

Fix#

1. Confirm this is what you are hitting. For the current (October 2026) bug, the supabase_analytics_<project> container only logs a generic [error] Backend query error; the real errors are in the Postgres container — run docker logs supabase_db_<project> and look for function ifnull(text, unknown) does not exist or invalid input syntax for type json. For the 2024/2025 shape instead, check docker logs supabase_analytics_<project> for the column "body" does not exist line quoted above. Either one confirms it is this family of bug, not a config mistake of your own.
2. Update the CLI. npm install supabase@latest --save-dev then npx supabase --version, or brew upgrade supabase then plain supabase --version (brew puts the binary on your PATH; npx would not see it). Supabase CLI 2.122.0 lists the fix in its own release notes, published 23 October 2026: "Stack: local Studio logs work again — analytics is pinned to Logflare 1.50.15, so logs pages no longer show 'Backend error'." That line credits supabase/cli#7182, the PR that pinned it. The pin fixes the log rows for every tab; the per-minute chart stays broken until Logflare/logflare#4159 is fixed upstream, which is a Logflare limitation, not something your update can change.
3. Restart the stack so it pulls the newly pinned image: supabase stop then supabase start. Per the CLI reference, local data is backed up to a Docker volume on a plain supabase stop — only --no-backup resets it — so this restart costs you no data; see fixing Postgres password authentication failures for the rest of the local-dev connection defaults.
4. Can't upgrade right now? Pin the version by hand, the same fix the CLI ships, without waiting for the update (bash/zsh — Git Bash or WSL on Windows): echo 1.50.15 > supabase/.temp/logflare-version && supabase stop && supabase start. This is the maintainer's own workaround, posted 15 October with the diagnosis, on the affected releases — the report that prompted it was on CLI 2.120.0.
5. If you are still on CLI 2.3x, with the analytics container up but its _analytics tables never created (July 2025's symptom — different from the bug above, where the schema exists but the query itself fails), no one on that thread tried the version pin from step 4. The only reports: removing the db.network_restrictions block from config.toml and reverting to CLI 2.29.0 fixed it for one commenter; the reporter instead says it was gone by the time they reached 2.34.3. Step 2's upgrade takes you well past both.

Verify the fix#

Open Studio's Logs page for API Gateway, Postgres and Auth in turn. Rows should load with no "Backend error" banner and no 502 from the underlying request. The per-minute activity chart at the top of each page can still legitimately show an error — that is the still-open IFNULL/COALESCE gap (Logflare/logflare#4159), not a sign your fix failed. To double-check which Logflare build you are actually running: docker ps --filter name=supabase_analytics --format "{{.Image}}" should print a tag containing 1.50.15, the release supabase/cli#7182 pinned.

The Oban loop on a database created before the fix#

If your local Postgres volume was first created while the CLI was still shipping Logflare 1.53.x (CLI 2.121.0) — before supabase/cli#7182 pinned it back — upgrading alone will not fully quiet things down. The restored 1.50.15 image does not read the background-job (Oban) tables that 1.53.x created only inside the _analytics schema, so the analytics container's alerting and event-touch workers restart in a loop and log:

relation "public.oban_jobs" does not exist

The PR is explicit that ingestion and querying both keep working regardless, so this loop is noise in docker logs, not a new outage — and it clears the moment you reset the local database: supabase stop --no-backup, then supabase start again. Per the same CLI reference, that flag is what resets your local data, so only reach for it on a project you can afford to reseed.

Once the Logs page itself is trustworthy again, a common next step in this same workflow is one step further along: pushing a migration from this local project to the linked remote one. If that push comes back with "must be owner of table", it is a different, unrelated error — see the fix for Supabase's ownership error on db push rather than reopening this one. If you go the other way and connect psql straight to the exposed port 54322 to read the _analytics tables yourself while debugging, a wrong password on that TCP connection gets you a third, unrelated error — a password, not a peer, authentication failure, since peer auth only ever applies to a local socket. docker exec into the container and run psql over that socket instead, as the wrong OS user, and you get the peer failure for real: see the fix for Postgres peer authentication failures.

The common thread across all three incidents is worth keeping in mind for next time: nothing here was ever actually about "API Gateway" or "Postgres" logging specifically breaking. Everything you see under Studio's Logs tab, in every service, is rendered by the same Logflare instance translating the same style of query into Postgres — so when one tab breaks, check the others before assuming you have found three bugs instead of one.