멈춘 것도, 멈춘 이유도

Maple은 사이트, API, 포트, cron 작업을 24시간 체크합니다. 하나가 실패하면 이유가 담긴 알림을 받고, 실패한 HTTP 체크는 앱 안의 요청 트레이스로 열립니다.

움직임

실시간으로 보는 모니터

막대 하나가 체크 한 번입니다. 기본값으로 두 번 연속 실패하면 인시던트가 열리고 팀에 알림이 갑니다. 체크가 다시 통과하면 저절로 닫힙니다.

uptime · 5 monitors LIVE

status monitor checks p95 30d

checkout-api GET /health · every 30s 212 ms 99.71%

UP auth GET /v1/session · every 60s 84 ms 99.98%

UP postgres-primary TCP db.internal:5432 · every 30s 3 ms 100%

UP acme.com MX DNS MX acme.com · every 5m 21 ms 100%

UP nightly-backup cron 0 3 * * * · grace 15m n/a 100%

incident opened 14:32:07

checkout-api is down

Status 503, expected 2xx · failed 2 checks in a row

trace 7c1e40a9…e21f service checkout sent to #oncall

failed checks · closes when it passes again http checks carry a trace id

trace 7c1e40a9…e21f 503 · 5.02 s

maple-uptime GET /health 5.02 s

checkout GET /health 4.94 s

checkout pg.pool.acquire 4.90 s

checkout redis GET flags 3 ms

maple.uptime.failureStatus 503, expected 2xx

http.response.status_code503

maple.uptime.monitor_namecheckout-api

url.fullhttps://checkout.acme.dev/health

근본 원인

대부분의 업타임 도구는 "503"에서 멈춥니다. Maple의 HTTP 체크는 트레이스 ID를 앱으로 전달하므로, 앱이 계측되어 있으면 실패한 체크가 요청 전체로 열립니다. 이 예에서는 데이터베이스 풀이 연결을 내주는 데 5초가 걸렸습니다.

새로 배울 것 없음: HTTP, TCP, DNS 체크는 다른 요청과 똑같이 저장됩니다. 이미 쓰는 도구로 검색하고, 차트로 보고, 알림을 걸 수 있습니다.
서비스와 연결: 모니터를 서비스에 연결하면 체크가 그 서비스 페이지에 오류, 배포와 나란히 표시됩니다.
깔끔한 서비스 맵: 체크가 서비스 맵에 호출자로 나타나지 않으므로, 실제 의존 관계가 그대로 잘 보입니다.

할 수 있는 일

웹사이트와 API: 상태 코드, 응답 시간, 본문, JSON 필드, 헤더를 체크합니다. 따로 정하지 않으면 2xx가 아닌 응답은 모두 실패로 봅니다.
데이터베이스와 포트: Postgres, Redis, 메시지 브로커, 메일 서버가 여전히 연결을 받는지 확인합니다.
DNS 레코드: A, AAAA, CNAME, MX, TXT, NS 레코드가 사라지거나 바뀌면 사용자보다 먼저 알아챕니다.
cron 작업과 워커: 작업이 끝나면 URL로 ping을 보냅니다. 예정대로 도착하지 않으면 Maple이 알려 줍니다.
최소 30초 간격: 30초마다부터 1시간마다까지 고를 수 있고, 몇 번 실패해야 알릴지도 1~10번 사이로 정합니다.
AI 에이전트가 설정: 에이전트가 Maple의 MCP 서버로 모니터를 만들고 수정할 수 있습니다. 새 엔드포인트를 배포한 직후처럼요.