Retire the outage's explanation, fourteen days on - #179
Merged
Conversation
The 522s are still there: 880 of them against 23 2xx in the last 24 hours, 1,949 against 6 on 02/09, the last one at 09/09 17:20:24 UTC. What changed is the explanation. The pgBouncer incident this page blamed no longer appears among the open incidents on status.supabase.com; the two that remain (JWT 401s, a network problem in Myanmar) produce nothing like a 522. The attribution has outlived the incident, so it goes. Two details the first write-up under-weighted, both now recorded. The incident said "on some older projects" and this project runs Postgres 17.6.1, created in March: the dates matched, membership in the affected set was never checked. And the fault is not steady — the project answers for minutes and falls back. On 08/09 between 22:17 and 22:26 UTC the authenticated path worked, signup, token, forum_threads, notifications and friendships all 200, which means PostgREST, pooler and Postgres were alive; the keep-alive went green once on 29/08, and since the PR #167 fix that job only goes green on a 200 with a JSON array body. Those timestamps are the useful part of a support ticket: they say the instance comes up and dies, not that it is off. Also gone: the postgres logs. Only edge_logs answers now, where on 27/08 there were 93 statement timeouts in a day. The plan flips accordingly — the ticket, which was step 2, is now step 1, and the old "wait for the rollout" carries a note saying it has no object left. The schema check on user_profiles is still unverified: the management API timed out again, which proves nothing about the outage and did not let the check happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The community backend is still answering 522 — 880 of them against 23 2xx in the last 24 hours, the last at 09/09 17:20:24 UTC — but the pgBouncer incident this note blamed no longer appears among the open incidents on
status.supabase.com. The attribution has outlived the incident, so the page retires it instead of extending it.What the new measurements add:
edge_logsanswers now, where on 27/08 there were 93 statement timeouts in a day.The plan flips: the support ticket, which was step 2, is now step 1, and the old "wait for the rollout" carries a note saying it has no object left. The
user_profilesschema check is still unverified — the management API timed out again, which proves nothing about the outage and did not let the check happen.Documentation only; no code touched.
🤖 Generated with Claude Code