A status page must outlive the service it reports on
Status-page SaaS (Statuspage, status.io, Better Stack) give incident notices, per-component status, and an incident history, with notice templates and subscriber alerts built in. The value is not the features — it is that there is already a place to say 'investigating,' which buys the right to answer slowly. The catch is a hosting one: never put the status page on the same infrastructure as the service, or it dies exactly when it is needed. It is the watcher version of the invariant lesson — the thing that reports the failure must not share fate with the thing that fails.
Not a build — a channel to stand up before it is needed. Measure the real time to post a first notice; over 10 minutes and you will not use it mid-incident. Write four template sentences now — investigating, identified, monitoring, resolved. And host it on infrastructure independent of the service. Statuspage / status.io / Better Stack are interchangeable for this; the discipline matters more than the vendor.
Why
This is where the 'say investigating out loud' lesson actually lives. Announcing that you are looking into it buys time — but only if there is a channel for the announcement; without one, you do not use it, and silence gets filled by other people's guesses. The non-obvious failure is architectural: a status page that shares infrastructure with the service reports 'all systems operational' right up until it goes dark with everything else, which is worse than having no page at all. So the rule is the watcher-independence rule from monitoring in general: a monitor that fails together with its target is not a monitor.
For jayverse, before the December launch, four template sentences hosted on independent infrastructure is already half the incident-comms plan — and the cheap half. The status page is not a feature you ship; it is the place your future self will be grateful already existed at 3am. Related: an-invariant-is-a-stop-not-an-alarm and refill-rate-is-the-real-cap (a watcher must be independent of what it watches).
Saying 'investigating' out loud buys the right to answer slowly — but only with somewhere to say it. No channel → you stay silent → the silence is filled by other people's guesses.
The one hosting rule
Status page on...
What happens at the outage
the same infra as the service
goes dark with it — reports 'operational' until it can't report at all
independent infra
survives to actually report the outage
The watcher version of the invariant lesson: a monitor that fails with its target is not a monitor.
The two-minute prep
Four template sentences: investigating / identified / monitoring / resolved.
Time-to-first-notice under 10 minutes (or it won't be used mid-incident).
상태 페이지 SaaS(Statuspage, status.io, Better Stack)는 장애 공지·구성요소별 상태·과거 인시던트 기록을 공지 템플릿과 구독자 알림과 함께 제공합니다. 값어치는 기능이 아니라 '확인 중'이라고 말할 자리가 이미 있다는 것 — 그게 답을 천천히 낼 권리를 삽니다. 함정은 호스팅에 있습니다: 상태 페이지를 서비스와 같은 인프라에 두지 마세요, 필요한 바로 그 순간 같이 죽습니다. 불변식 교훈의 감시자 버전입니다 — 실패를 보고하는 것은 실패하는 것과 운명을 공유해선 안 됩니다.
구현이 아니라 필요하기 전에 세워둘 채널. 첫 공지를 올리는 실제 시간을 재세요; 10분을 넘으면 사고 중에는 안 씁니다. 지금 템플릿 문장 네 줄을 적어두세요 — 확인 중, 원인 파악, 모니터링, 해결. 그리고 서비스와 독립된 인프라에 호스팅하세요. Statuspage / status.io / Better Stack은 이 용도로 서로 대체 가능합니다; 벤더보다 규율이 중요합니다.
왜
'확인 중이라고 소리 내어 말하기' 교훈이 실제로 사는 곳입니다. 들여다보고 있다고 알리는 건 시간을 삽니다 — 단, 알릴 채널이 있을 때만; 없으면 안 쓰게 되고, 침묵은 남의 추측으로 채워집니다. 눈에 안 띄는 실패는 구조적입니다: 서비스와 인프라를 공유하는 상태 페이지는 모든 게 같이 꺼지기 직전까지 '전 시스템 정상'을 보고하는데, 이건 페이지가 아예 없는 것보다 나쁩니다. 그래서 규칙은 일반적 모니터링의 감시자-독립 규칙입니다: 대상과 함께 실패하는 모니터는 모니터가 아닙니다.
jayverse엔 12월 런칭 전, 독립 인프라에 올린 템플릿 문장 네 줄이 이미 인시던트 커뮤니케이션 계획의 절반 — 그리고 싼 절반입니다. 상태 페이지는 출하하는 기능이 아니라, 새벽 3시에 미래의 내가 '이미 있어서' 고마워할 자리입니다. 관련: an-invariant-is-a-stop-not-an-alarm, refill-rate-is-the-real-cap(감시자는 감시 대상과 독립이어야 한다).
동작 방식
무엇인가
Statuspage / status.io / Better Stack — 장애 공지·구성요소별 상태·과거 인시던트 기록·공지 템플릿·구독자 알림. 이 용도로 서로 대체 가능.
습관이 아니라 채널이어야 하는 이유
'확인 중'이라고 소리 내어 말하는 건 답을 천천히 낼 권리를 삽니다 — 단, 말할 자리가 있을 때만. 채널이 없으면 → 침묵하게 되고 → 그 침묵을 남의 추측이 채웁니다.