Uptime Kuma 서버 모니터링｜다운 알림 설정하는 7단계 가이드

Uptime Kuma 서버 모니터링을 설정하면 홈서버에 문제가 생겼는지 확인하기 위해 하루에도 몇 번씩 관리 페이지를 열어볼 필요가 없습니다.

홈서버를 처음 만들 때는 서비스가 실행되는 것 자체가 중요하지만, 운영하는 서비스가 늘어나면 새로운 문제가 생깁니다. 서버는 켜져 있어도 특정 웹 서비스만 중지될 수 있고, Docker 컨테이너가 비정상 종료되거나 네트워크 문제로 접속할 수 없는 상황도 발생할 수 있습니다.

이런 상태를 사람이 계속 확인하는 것은 현실적이지 않습니다. 그래서 일정한 간격으로 서비스가 정상적으로 응답하는지 자동 확인하고 문제가 발견됐을 때 알려주는 업타임 모니터링을 사용합니다.

Uptime Kuma는 이런 작업을 자신의 서버에서 직접 운영할 수 있도록 만든 모니터링 도구입니다. 공식 프로젝트에서는 HTTP(S), TCP, HTTP(S) Keyword, JSON Query, WebSocket, Ping, DNS Record, Push, Docker Container 등 여러 형태의 모니터링을 지원한다고 안내합니다. 또한 이메일을 포함해 다양한 알림 서비스를 지원합니다. :contentReference[oaicite:0]{index=0}

Uptime Kuma는 무엇을 확인하는 도구일까?

Uptime Kuma 서버 모니터링을 이해하려면 먼저 “서버가 살아 있다”는 말이 여러 의미를 가질 수 있다는 점을 알아야 합니다.

예를 들어 미니 PC의 전원이 켜져 있고 Linux도 정상적으로 실행되고 있다고 가정해보겠습니다. 그렇다고 그 안에서 실행하는 모든 서비스가 정상이라는 뜻은 아닙니다.

웹 서버 프로세스만 중지될 수도 있고, 특정 컨테이너에 문제가 생길 수도 있습니다. 반대로 서비스 자체는 정상인데 DNS나 네트워크 문제 때문에 사용자가 접속하지 못하는 상황도 생길 수 있습니다.

따라서 무엇을 감시하고 싶은지에 따라 Uptime Kuma에서 사용하는 모니터 유형도 달라집니다.

확인하고 싶은 것	활용할 수 있는 방식
웹사이트가 응답하는가?	HTTP(S)
특정 TCP 서비스에 연결되는가?	TCP Port
호스트가 네트워크에서 응답하는가?	Ping
DNS 레코드가 정상인가?	DNS Record
특정 Docker 컨테이너 상태	Docker Container

홈서버 초보자라면 우선 HTTP(S) 모니터부터 이해하는 것이 쉽습니다. 웹 브라우저로 접속하는 서비스를 일정한 간격으로 확인해 정상적인 응답을 받는지 살펴보는 방식입니다.

예를 들어 개인 블로그나 홈서버 대시보드처럼 URL을 통해 접근하는 서비스를 등록하면 Uptime Kuma가 해당 주소를 주기적으로 확인합니다.

여기서 중요한 점은 단순히 서버 프로세스가 실행 중인지 확인하는 것과 실제 사용자가 웹서비스에 접속할 수 있는지 확인하는 것이 다르다는 것입니다.

Docker 컨테이너가 실행 중이라고 표시되더라도 애플리케이션 내부 오류 때문에 웹페이지가 정상적으로 응답하지 않을 수 있습니다. 따라서 웹 서비스라면 실제 HTTP(S) 요청을 이용한 모니터링이 더 직접적인 상태 확인 방법이 될 수 있습니다.

Uptime Kuma는 단순히 UP과 DOWN만 기록하는 데 그치지 않습니다. 공식 프로젝트에서는 Ping 차트, 인증서 정보, 여러 상태 페이지 등의 기능도 제공합니다. 따라서 시간이 지나면 서비스 응답 상태를 확인하는 대시보드나 상태 페이지로 확장해서 사용할 수도 있습니다. :contentReference[oaicite:1]{index=1}

Docker로 Uptime Kuma 설치하기

홈서버에서 Docker를 이미 사용하고 있다면 Uptime Kuma 역시 컨테이너로 구성할 수 있습니다. 특히 2026년에는 오래된 설치 글을 그대로 따라 하지 않도록 이미지 버전을 확인하는 것이 중요합니다.

Uptime Kuma 공식 설치 Wiki는 2026년 4월 수정된 안내에서 Docker 이미지로 louislam/uptime-kuma:2를 사용하고 있습니다. 예전 글에서 흔히 볼 수 있는 버전 1 기준 명령과 구분해야 합니다. :contentReference[oaicite:2]{index=2}

현재 공식 Docker 설치 예시는 다음과 같은 형태입니다.

docker run -d \
  --restart=unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:2

이 명령에서 -p 3001:3001은 호스트의 3001번 포트와 Uptime Kuma 컨테이너의 3001번 포트를 연결합니다.

-v uptime-kuma:/app/data는 Uptime Kuma의 데이터를 Docker volume에 저장하기 위한 부분입니다. 컨테이너를 새로 생성하더라도 설정과 모니터링 데이터가 유지되려면 이런 영구 데이터 저장 위치가 중요합니다.

--restart=unless-stopped는 컨테이너의 재시작 정책을 지정합니다. 공식 최신 설치 예제에서도 이 설정을 사용합니다. :contentReference[oaicite:3]{index=3}

Docker Compose를 사용한다면 공식 프로젝트에서 제공하는 Compose 구성으로 설치할 수도 있습니다. 공식 README에서는 Compose 파일을 내려받은 뒤 docker compose up -d로 실행하는 방법을 안내하고 있습니다. :contentReference[oaicite:4]{index=4}

mkdir uptime-kuma
cd uptime-kuma

curl -o compose.yaml \
https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml

docker compose up -d

설치가 끝났다면 같은 네트워크의 PC에서 서버 IP와 3001번 포트를 이용해 접속할 수 있습니다.

http://서버-IP:3001

예를 들어 서버 내부 IP가 192.168.0.50이라면 개념적으로 http://192.168.0.50:3001과 같은 형태가 됩니다. 실제 IP 주소는 자신의 서버에서 확인해야 합니다.

이 부분은 홈서버에서 특히 중요합니다. NAS를 사용한다고 해서 Uptime Kuma 데이터 디렉터리를 무조건 네트워크 스토리지로 연결하는 것이 좋은 선택은 아닙니다. 공식 문서가 요구하는 파일 잠금 조건을 만족하는지 확인해야 합니다.

초보자라면 공식 예제처럼 로컬 Docker volume을 사용하는 구성이 이해하기 쉽습니다. 별도의 경로로 데이터를 옮기려면 저장 방식과 백업 구조를 이해한 뒤 변경하는 편이 좋습니다.

설치 후 컨테이너 상태가 궁금하다면 Docker에서 다음과 같이 확인할 수 있습니다.

docker ps

docker logs uptime-kuma

컨테이너가 실행 중인데 Uptime Kuma 페이지에 접속할 수 없다면 포트 매핑과 서버 방화벽, Docker 네트워크 등을 차례대로 확인해야 합니다.

Uptime Kuma 공식 Troubleshooting 문서에서도 Docker 네트워크 구성에 따라 로컬 또는 원격 네트워크 접근 여부가 달라질 수 있다고 설명합니다. Uptime Kuma에서 서비스가 DOWN으로 표시되지만 실제 접속은 가능한 경우라면 Docker 네트워크나 방화벽 문제도 점검 대상입니다. :contentReference[oaicite:6]{index=6}

첫 번째 서버 모니터 만들기

Uptime Kuma 서버 모니터링 설치가 끝났다면 이제 실제로 감시할 서비스를 등록할 차례입니다. 처음에는 여러 옵션을 한꺼번에 설정하기보다 브라우저로 접속하는 웹서비스 하나를 대상으로 시작하는 것이 가장 이해하기 쉽습니다.

Uptime Kuma에 로그인한 뒤 새로운 모니터를 추가하면 모니터 유형, 이름, URL 또는 주소, 확인 간격 등의 항목을 설정할 수 있습니다.

예를 들어 홈서버에서 웹서비스 하나를 운영하고 있다고 가정해보겠습니다.

http://192.168.0.50:8080

같은 내부 네트워크에서 이 주소로 정상적으로 접속할 수 있다면 Uptime Kuma의 HTTP(S) 모니터에 해당 주소를 등록해 응답 상태를 확인할 수 있습니다.

모니터 이름은 나중에 서비스가 많아졌을 때 구분하기 쉽도록 작성하는 것이 좋습니다. 단순히 Server 1이라고 적기보다 홈서버 대시보드, 개인 클라우드, 블로그처럼 실제 서비스가 무엇인지 알 수 있는 이름을 사용하는 편이 좋습니다.

등록이 완료되면 Uptime Kuma가 설정된 간격에 따라 대상에 요청을 보내고 정상적으로 응답하는지 확인합니다. 정상적으로 확인되면 UP 상태로 표시되고, 문제가 발생하면 DOWN 상태를 감지할 수 있습니다.

Ping과 HTTP(S)는 무엇이 다를까?

초보자가 자주 헷갈리는 부분이 Ping과 HTTP(S) 모니터의 차이입니다. 둘 다 서버 상태를 확인하는 데 사용할 수 있지만 확인하는 대상은 다릅니다.

모니터	주로 확인하는 것	활용 예시
Ping	호스트의 네트워크 응답	서버·NAS 등의 기본 연결 상태
HTTP(S)	웹서비스의 HTTP 응답	홈페이지·웹앱·대시보드
TCP Port	특정 TCP 포트 연결 가능 여부	TCP 기반 서비스

예를 들어 Ping은 정상인데 HTTP(S) 모니터가 DOWN일 수 있습니다. 서버 자체는 네트워크에 연결되어 있지만 웹 애플리케이션이나 리버스 프록시 등에 문제가 발생했다면 이런 상태가 나타날 수 있습니다.

반대로 일부 환경에서는 방화벽이나 네트워크 정책 때문에 ICMP Ping에 응답하지 않으면서 웹서비스는 정상적으로 작동할 수도 있습니다. 따라서 Ping 결과 하나만으로 모든 서비스의 상태를 판단해서는 안 됩니다.

Docker Container 모니터링은 언제 사용할까?

Uptime Kuma는 Docker Container 모니터 유형도 지원합니다. 이를 이용하면 Docker 호스트와 연결해 특정 컨테이너의 상태를 확인하는 구성을 만들 수 있습니다.

다만 여기서도 “컨테이너가 실행 중이다”와 “서비스가 실제로 정상 작동한다”를 구분해야 합니다.

컨테이너 프로세스는 실행 중이지만 내부 애플리케이션이 요청을 제대로 처리하지 못할 가능성이 있기 때문입니다. 따라서 사용자에게 웹서비스가 정상적으로 제공되는지가 중요하다면 HTTP(S) 모니터를 함께 고려하는 것이 좋습니다.

서버 다운 알림 연결하기

Uptime Kuma 서버 모니터링의 핵심은 상태를 기록하는 것보다 문제가 발생했을 때 사용자가 알 수 있도록 만드는 데 있습니다.

모니터링 화면을 하루 종일 열어두고 있다면 알림이 없어도 되겠지만 실제 홈서버에서는 그렇게 사용하지 않습니다. Uptime Kuma가 백그라운드에서 상태를 확인하고 장애가 발생했을 때 필요한 알림 채널을 통해 알려주는 방식이 훨씬 실용적입니다.

Uptime Kuma 공식 프로젝트는 이메일(SMTP)을 비롯해 Telegram, Discord, Slack, Microsoft Teams, Google Chat, Webhook 등 다양한 알림 서비스를 지원한다고 안내합니다.

따라서 어떤 알림 방법이 가장 좋은지는 사용 환경에 따라 달라집니다.

알림 방식	특징
Email (SMTP)	별도 메신저를 사용하지 않아도 이메일로 확인 가능
Telegram	메신저를 통해 빠르게 상태 알림 확인
Discord	서버·채널 기반 알림 구성에 활용 가능
Webhook	다른 자동화 시스템과 연결할 때 활용 가능

처음 설정한다면 평소 가장 자주 확인하는 알림 채널 하나만 연결해도 충분합니다. 여러 채널에 같은 알림을 동시에 보내도록 구성하면 작은 장애에도 알림이 반복되어 오히려 확인하지 않게 될 수 있습니다.

알림을 만들었다면 반드시 테스트하기

알림 설정 화면에서 값을 입력했다고 해서 실제 장애 상황에서도 메시지가 정상적으로 도착한다고 가정하면 안 됩니다.

Uptime Kuma의 알림 설정에는 구성에 따라 테스트 기능을 사용할 수 있으므로 저장하기 전에 실제 메시지가 도착하는지 확인하는 것이 좋습니다.

또한 장애가 발생했을 때뿐 아니라 서비스가 다시 정상화됐을 때 어떤 알림이 오는지도 확인해두면 좋습니다.

예를 들어 새벽에 잠깐 서비스가 중단됐다가 자동 재시작으로 복구됐다면 DOWN 알림만 보는 것보다 이후 정상 상태로 돌아왔다는 정보까지 확인할 수 있어야 현재 대응이 필요한지 판단하기 쉽습니다.

왜 알림이 너무 많이 올까?

모니터링을 처음 설정하면 짧은 네트워크 지연 하나까지 장애로 판단하도록 구성할 수 있습니다. 이 경우 실제 서비스 장애가 아닌 일시적인 응답 실패에도 알림이 발생할 수 있습니다.

Uptime Kuma에는 재시도와 관련된 설정이 있으며, 이를 이용해 몇 번의 실패 후 DOWN으로 판단할지 조정할 수 있습니다.

예를 들어 아주 짧은 일시적 오류에도 즉시 알림을 보내는 것과 연속적인 실패를 확인한 뒤 알림을 보내는 것은 운영 경험이 크게 다릅니다.

모니터링 간격은 어떻게 정할까?

Uptime Kuma에서 모니터를 추가하면 Heartbeat Interval을 설정할 수 있습니다. 쉽게 말하면 대상 서비스의 상태를 얼마나 자주 확인할지를 정하는 값입니다.

확인 간격을 짧게 설정하면 장애를 더 빠르게 발견할 가능성이 높아지지만 요청도 더 자주 발생합니다. 반대로 간격이 길면 확인 횟수는 줄어들지만 장애를 발견하는 시점도 늦어질 수 있습니다.

따라서 모든 서비스를 동일한 간격으로 설정할 필요는 없습니다.

서비스 중요도	설정 방향
장애를 빠르게 알아야 하는 서비스	비교적 짧은 간격을 검토
일반적인 개인 홈서버 서비스	기본값에서 시작해 운영하며 조정
중요도가 낮은 테스트 서비스	상대적으로 긴 간격도 검토 가능

특정 숫자를 모든 홈서버의 정답처럼 적용하기보다는 서비스의 중요도와 네트워크 환경에 맞춰 설정하는 것이 좋습니다.

특히 외부 사이트를 모니터링한다면 지나치게 짧은 간격으로 불필요한 요청을 반복하지 않도록 주의해야 합니다. 자신이 운영하지 않는 웹사이트를 모니터링할 때는 해당 서비스에 불필요한 부하를 주지 않는 범위에서 사용해야 합니다.

내부 홈서버 서비스 역시 짧은 순간의 네트워크 지연을 실제 장애로 판단하지 않도록 재시도 설정과 함께 살펴보는 것이 좋습니다.

모니터가 많아질수록 이름과 그룹도 정리해두면 좋습니다. 예를 들어 홈서버 인프라, 미디어 서비스, 개인 클라우드, 외부 웹사이트처럼 용도별로 구분하면 어느 영역에서 장애가 발생했는지 빠르게 파악하기 쉽습니다.

이렇게 구성하면 Uptime Kuma는 단순히 “서버가 켜져 있는지 보는 화면”에서 벗어나 홈서버에서 운영하는 여러 서비스를 한눈에 확인하는 상태 대시보드 역할까지 할 수 있습니다.

Uptime Kuma도 같이 다운되면 어떻게 될까?

Uptime Kuma 서버 모니터링을 구성할 때 반드시 생각해야 하는 한계가 하나 있습니다. 감시 대상과 Uptime Kuma를 같은 서버에서 실행한다면 서버 전체가 꺼졌을 때 Uptime Kuma 역시 함께 중단될 수 있다는 점입니다.

예를 들어 미니 PC 한 대에서 개인 클라우드, 웹서비스, Uptime Kuma를 모두 실행한다고 가정해보겠습니다. 특정 웹서비스 컨테이너만 중지되는 상황이라면 같은 서버에서 실행 중인 Uptime Kuma가 문제를 감지할 수 있습니다.

하지만 미니 PC의 전원이 꺼지거나 운영체제 자체가 멈추면 상황이 달라집니다. 모니터링을 수행하는 Uptime Kuma까지 함께 중지되므로 해당 인스턴스가 스스로 자신의 서버 전체 장애를 감지하고 외부로 알림을 보내는 것은 어렵습니다.

장애 상황	같은 서버의 Uptime Kuma
특정 웹앱만 중지	감지 가능
특정 컨테이너 오류	구성에 따라 감지 가능
특정 포트 서비스 중지	감지 가능
호스트 서버 전체 종료	Uptime Kuma도 함께 중지
집 전체 인터넷 연결 장애	외부 알림 전달이 어려울 수 있음

따라서 모니터링의 목적을 먼저 구분해야 합니다. 개인 홈서버에서 실행되는 여러 컨테이너의 장애를 편리하게 확인하는 것이 목적이라면 같은 서버에 Uptime Kuma를 설치하는 것만으로도 충분히 유용합니다.

반면 서버 자체의 전원 장애나 인터넷 회선 장애까지 외부에서 감지해야 한다면 감시 대상과 독립된 위치에서 모니터링하는 구조를 검토해야 합니다.

예를 들어 별도의 서버나 다른 네트워크에서 실행되는 모니터링 인스턴스가 외부에서 홈서버의 공개 서비스를 확인하도록 구성하면 홈서버 자체가 중단된 상황도 구분할 수 있습니다.

내부 주소만 감시할 때의 한계

또 하나 생각해야 할 부분은 Uptime Kuma가 어디에서 서비스를 확인하는가입니다. 같은 Docker 호스트나 같은 내부 네트워크에서만 서비스를 확인한다면 외부 사용자가 실제로 접속하는 경로와 상태가 다를 수 있습니다.

예를 들어 내부에서는 웹서비스가 정상적으로 열리지만 외부 도메인의 DNS 설정이나 리버스 프록시, HTTPS 인증서 등에 문제가 발생했다면 내부 IP만 확인하는 모니터에서는 문제를 발견하지 못할 수 있습니다.

따라서 외부에서 제공하는 서비스라면 무엇을 확인하려는지에 따라 내부 서비스 주소와 실제 사용자가 접속하는 HTTPS 주소를 구분해 모니터링하는 방법을 검토할 수 있습니다.

자주 묻는 질문

📖 핵심 용어 미니 사전

🔗 공식 자료

📖 출처

• Uptime Kuma 공식 GitHub — 프로젝트 기능 및 지원 모니터 유형
• Uptime Kuma 공식 Wiki — Docker 설치 및 데이터 저장 구성
• Uptime Kuma 공식 Troubleshooting — Docker 네트워크 및 연결 문제
• Docker 공식 문서 — 컨테이너, 볼륨 및 네트워크 기본 구조