Supabase 장애 알림 다시 설정하기: RSS·Slack 구독 변경사항

Supabase 상태 페이지 이전: 어떤 구독을 다시 설정하나요?

상태 페이지 주소는 status.supabase.com으로 유지됐지만 운영 플랫폼이 바뀌었습니다. 주소가 같다는 사실과 기존 구독이 유지된다는 사실은 다릅니다. 근거: Supabase 상태 페이지 이전 발표

이메일은 필요한 Products·Regions만 선택할 수 있게 됐습니다. 이 필터 기능이 RSS·Slack에도 동일하게 제공된다고 확장해서 설명하지는 않습니다. 근거: 채널 지원·이메일 범위 선택

첫 단계: Slack 직접 구독인지 RSS 앱 연동인지 확인

팀 채널에서 Supabase 알림을 받았더라도 연결 방식은 다를 수 있습니다. 아래는 편집부가 제안하는 현황 기록표입니다. 발신 앱과 관리 화면을 확인한 뒤 설정을 변경하세요.

기존 연결을 삭제하기 전에 담당자·채널·URL·최근 정상 수신 시각을 기록하면 롤백이나 중복 알림 조사에 도움이 됩니다. 새 방식에서 수신을 확인하기 전까지 “전환 완료”로 기록하지 않는 것이 좋습니다.

RSS 다시 구독하기: 이전 주소를 그대로 복사하지 마세요

1. 공식 페이지 접속: status.supabase.com에서 구독 안내를 확인합니다.
2. 새 피드 확인: 현재 페이지에서 제공하는 RSS 주소를 복사합니다. 오래된 문서의 history.rss·history.atom 경로를 새 주소라고 단정하지 않습니다.
3. 리더 등록: 사용하는 RSS 리더에서 새 피드를 추가하고 오류·파싱 결과를 확인합니다.
4. 원문 대조: 항목 제목·시각·원문 링크가 공식 장애 기록과 연결되는지 확인합니다.
5. 전환 기록: 새 수신 경로 확인 후 기존 피드를 정리하고 갱신 시각을 남깁니다.

이 절차는 운영 점검 제안입니다. 이번 조사에서 구독 대화상자의 최신 RSS 주소와 Slack 설치 흐름을 직접 확인하지 못해 특정 피드 URL이나 버튼명을 고정값으로 제공하지 않습니다. 공식 페이지가 표시하는 값을 기준으로 설정하세요.

피드 주소는 사람용 HTML 상태 페이지와 다릅니다. 다운로드나 HTTP 200 응답만 확인하지 말고 리더가 피드 항목을 정상적으로 읽는지도 확인해야 합니다. 장애가 새로 발생하지 않은 기간에는 신규 알림이 없는 것이 자연스러울 수 있습니다.

Slack에서 받는 두 가지 경로와 RSS 명령 예시

상태 페이지 Slack 구독을 사용할 경우 새 페이지의 안내에 따라 연결할 워크스페이스·채널과 앱 권한을 확인하세요. 설치 승인이나 채널 접근 문제가 있다면 Slack 관리자와 조율합니다. 이 흐름과 Slack RSS 앱은 별도 연결입니다.

RSS 앱으로 받는 방식은 Slack 공식 RSS 앱 설치 후 새 피드 주소를 채널에 등록합니다. 아래는 Slack 메시지 입력창에서 사용하는 명령 예시이며 터미널 명령이 아닙니다. 자리표시자는 실제 새 피드 URL·ID로 바꾸세요.

/feed list
/feed subscribe NEW_SUPABASE_RSS_URL
/feed help

새 수신을 확인한 뒤, 기존 피드의 ID를 확인해 별도로 구독을 해제합니다.

/feed remove OLD_FEED_ID

/feed list로 채널 피드와 고유 ID를 확인하고 /feed remove로 해당 피드를 구독 해제할 수 있습니다. Slack은 RSS와 Atom 피드를 지원합니다. 근거: Slack RSS 공식 사용법

RSS 앱은 마지막으로 읽은 항목의 날짜를 기억하고 다음 조회에서 그보다 새 항목을 가져옵니다. 따라서 구독 직후 과거 장애 글이 채널에 모두 다시 올라오지 않는다고 실패로 단정하면 안 됩니다. 근거: RSS 앱의 날짜 책갈피 동작

이메일 제품·지역 필터는 무엇을 선택해야 하나요?

공식 상태 페이지는 Postgres·Data APIs·Storage·Functions 등 제품과 지역별 상태 항목을 보여줍니다. 근거: Supabase 상태 항목

다음은 선택 범위를 정하기 위한 가상 사례입니다. 서울 지역에서 데이터베이스와 Storage를 쓰는 앱이라면 실제 프로젝트의 지역 식별자를 확인하고 관련 항목을 검토하세요. 한국 사용자가 많다는 이유만으로 데이터베이스의 운영 지역도 한국이라고 가정하지 않습니다.

앱에서 쓰는 서비스와 Dashboard·Management API 등 운영 작업의 의존성을 목록으로 만든 뒤 필요한 범위를 고르면 누락을 줄일 수 있습니다. 선택 범위를 줄일 때는 알림 수가 줄어든 것과 중요한 장애를 놓치지 않는 것을 별도 기준으로 확인하세요.

SMS·webhook으로 받던 팀의 대체 설계

새 상태 페이지에서는 SMS·webhook을 다시 등록하는 방식으로 복구할 수 없습니다. 기존 당직·티켓 자동화가 webhook 이벤트에 의존했다면 먼저 영향을 받는 흐름을 목록으로 만드세요.

RSS를 읽어 내부 알림으로 전달하는 별도 자동화를 검토할 수는 있지만, 이는 Supabase가 제공하는 새 webhook이 아닙니다. 설계할 때 조회 간격·중복 방지·재시도·수집 실패 감지·담당자를 정해야 합니다. RSS를 받아왔다고 즉시 전달·누락 없는 수신이 보장되는 것도 아닙니다. 이 문단은 대체 설계 제안이며 연결을 실제 구축했다는 뜻은 아닙니다.

알림이 안 올 때: 등록·수집·채널 도착을 나눠 점검

이 표는 편집부 문제 해결 제안입니다. 메시지가 채널에 게시됐는지와 사용자가 푸시 알림을 받았는지는 구분해야 합니다. 같은 장애의 진행 업데이트가 여러 번 게시되는 것과 동일 연결의 중복 등록도 구분해 확인하세요.

재설정 완료 기준과 다운로드 점검표

Supabase 장애 알림 재구독 점검표 CSV 다운로드에서 기존 경로·새 경로·등록 확인·실제 수신 증거를 기록할 수 있습니다. 빈 양식이며 설정 성공이나 수신 결과를 미리 채우지 않았습니다.

1. 기존 수신 방식과 담당 채널·사람을 기록합니다.
2. 새 구독 또는 피드의 등록 결과를 확인합니다.
3. 필요한 제품·지역과 실제 프로젝트 구성을 대조합니다.
4. 읽을 수 있는 기록과 이후 새 업데이트의 수신 여부를 확인합니다.
5. 중복 구독을 정리하고 수집 중단을 알아챌 담당자를 정합니다.

운영 장애를 일부러 만들면서 알림을 시험할 필요는 없습니다. 새 공식 업데이트를 관측하거나 지원되는 검증 방법을 사용하고, 아직 수신을 확인하지 못했다면 점검표에 “등록 확인·수신 미확인”으로 남기세요.

구독 등록과 알림 수신을 구분하는 완료 기준

예를 들어 새 피드는 등록됐지만 이후 공식 업데이트가 없었다면 “등록 확인·수신 미확인”으로 남깁니다. 실패라고 단정하거나 수신 성공이라고 쓰지 않습니다. 이 표는 편집부의 운영 기록 기준이며 실제 알림 수신 결과가 아닙니다.

이전 연결 삭제는 새 경로를 확인한 뒤 별도 단계로 수행하세요. 전환 기록에는 기존 피드 ID·새 주소·채널·담당자·확인 시각을 남기고, 추후 다른 담당자가 연결을 추적할 수 있도록 합니다.

자주 묻는 질문

상태 페이지 주소가 같은데 RSS를 왜 다시 설정하나요?

공식 발표는 주소 유지와 구독 이전 범위를 별도로 안내합니다. RSS 구독은 자동 이전 대상이 아니므로 새 페이지에서 확인해야 합니다.

이메일도 다시 가입해야 하나요?

공식 안내상 자동 재등록됐습니다. 중복 가입보다 수신 주소·구독 범위·메일 분류를 먼저 점검하세요.

Slack RSS 명령이 Supabase 직접 Slack 구독을 복구하나요?

RSS 앱에 피드를 추가하는 별도 방식입니다. 기존 구독 방식과 새로 선택하는 경로를 명확히 기록하세요.

상태 페이지가 정상인데 앱에 오류가 나면 어떻게 하나요?

공식 공지와 개별 앱의 연결·인증·쿼리·설정 오류는 별도로 조사해야 합니다. 상태 알림은 앱 자체 모니터링을 대신하지 않습니다.

팀의 개발 알림을 함께 정리할 때는 Slack 개발 협업 가이드를 참고하세요. 모니터링 알림과 반복 작업의 역할 차이는 예약 작업·모니터링 비교 가이드에서 확인할 수 있습니다.