해결됨 · 2시간 지속
8월 18일 Fluxer 장애
Fluxer 제보가 시간당 35건까지 급증했고 2시간 동안 높게 유지됐어요.
- 시작
- 오전 3:00
- 2026년 8월 18일 · UTC
- 정상 복구
- 오전 5:00
- 2시간 후
- 최고치
- 시간당 35
- 평소의 18×
- Fluxer 인시던트
- 14분
- Issues with platform connectivity
장애 중 제보
Fluxer의 발표 내용
fluxerstatus.comIssues with platform connectivity
- 해결됨 · 오전 4:18
On 18 August, Fluxer was down for about 15 minutes, from 03:54 to 04:05 UTC. Traffic reaches us through Caddy. Caddy terminates TLS and forwards into Kubernetes via ingress-nginx. Page loads are served by app-proxy. Everything else goes to the API. On every page load, app-proxy refreshed a cached discovery document before responding. It fetched that document from its own public address, <https://api.fluxer.app/.well-known/fluxer>. The request therefore travelled back out through Caddy rather than staying inside the cluster. A rolling API deploy made that endpoint briefly unavailable. The fetch had a five second timeout, so every page load began taking five seconds. Those slow requests filled up ingress-nginx. They then filled Caddy's queue of pending connections, and Caddy stopped accepting new ones. At that point app-proxy could no longer reach the API at all. The route it needed ran through the front door it had just blocked. The outage held itself open and could not recover on its own. We restarted Caddy on all three web nodes to clear the backlog. That restored service. The root cause was in app-proxy. Its background refresh already backed off when the API was unhealthy. The page load path, however, called the refresh directly and skipped that backoff. Every request therefore paid the full timeout. Page loads now serve the cached document. They make no network calls at all while a cached copy exists. The first fetch after startup is rate limited, so an unavailable API cannot cause a retry storm.
- 해결됨 · 오전 4:10
This incident has been resolved.
- 조사 중 · 오전 3:56
We are currently investigating this incident.
Fluxer은(는) 제보가 늘기 시작한 지 57분 후에 첫 업데이트를 올렸어요.
Fluxer 지금 다운되었나요?
실시간 상태, 오늘의 제보, 다른 이전 장애.