Prometheus Alertmanager 전화 알림: 정말 급한 것에만 울리게 하기

Alertmanager에는 음성 리시버가 없습니다. critical 등급일 때만 Prometheus 알림을 전화로 바꾸는 방법: webhook 설정, 조건, 그리고 Watchdog 함정.

업데이트

목차

Alertmanager에는 음성 리시버가 없습니다. Prometheus 알림이 발생했을 때 전화를 받으려면, 구독 유형을 전화로 설정한 Echobell 채널을 가리키는 webhook_configs 리시버를 추가하세요. 이 글에서는 정확한 YAML, 해결된 알림이 전화를 걸지 못하게 하는 조건, 심각도별 라우팅, 그리고 그대로 두면 네 시간마다 영원히 전화를 울리게 만드는 Watchdog 알림을 다룹니다.

Prometheus는 지난 10년간 구축된 대부분의 인프라에서 사실상 기본 메트릭 스택이며, Alertmanager는 어려운 부분들을 정말 잘 해냅니다. 알림 중복 제거, 그룹화, 점검 중 무음 처리, 상위 의존성 장애 시 하위 노이즈 억제까지요.

다만 하지 않는 일이 하나 있습니다. 사람을 깨우는 것입니다.

Alertmanager 혼자서는 왜 전화를 울릴 수 없나

Alertmanager에는 이메일, Slack, PagerDuty, OpsGenie, Discord, Telegram, Pushover, Webex, MS Teams 등 십수 종의 리시버가 있습니다. 하지만 이들 모두가 전달하는 것은 메시지이고, 메시지는 무음 스위치, 방해 금지 모드, iOS 집중 모드의 영향을 받습니다. 새벽 3시에는 곧 "알림은 도착했지만 아무 일도 일어나지 않았다"는 뜻입니다.

voice_configs 같은 건 없습니다. 사람들이 보통 도달하는 선택지는 이렇습니다.

  • PagerDuty / OpsGenie / Splunk On-Call — 실제로 전화를 걸어주지만, 모두 좌석당 과금이 붙는 완전한 인시던트 관리 플랫폼입니다. 교대 근무와 에스컬레이션 트리가 필요하다면 정답이지만, 전화만 울리면 되는 상황에는 과합니다. (게다가 OpsGenie는 서비스 종료 수순에 있어서, 지금 많은 팀이 이 계층을 재검토하고 있습니다.)
  • Sachet 같은 SMS 브리지 — 서비스를 하나 더 운영하고, 게이트웨이에 건당 비용을 내지만, SMS는 여전히 메시지로 도착합니다. iOS에서는 발신자가 허용 목록에 있지 않는 한 문자가 집중 모드를 뚫지 못합니다.
  • Twilio 기반 자체 구현 — 작은 웹훅 리시버를 짜고, 번호를 사고, 통화당 비용을 내면, 이제 "전화를 울리는 것"이 유일한 임무인 프로덕션 인프라를 하나 떠안게 됩니다.

범용 webhook 리시버가 그 탈출구입니다. 문서화된 JSON을 임의의 URL로 POST해 주며, 필요한 건 그게 전부입니다.

준비물

  • 실행 중인 Prometheus + Alertmanager, 그리고 alertmanager.yml을 수정할 권한
  • Echobell 설치 (App Store / Google Play)
  • 10분

이 글은 Alertmanager 0.31을 기준으로 작성했습니다. 웹훅 페이로드는 수년째 version: "4"이므로 0.2x 릴리스도 동일하게 동작합니다.

Alertmanager에서 hook.echobell.one로 나가는 아웃바운드 HTTPS가 필요하지만, 인터넷에서 접근 가능할 필요는 없습니다. 클러스터 내부, VPC 내부, 홈랩의 Alertmanager 모두 문제없이 동작합니다.

1단계 — 전화를 걸어주는 채널 만들기

Echobell에서 Prometheus Critical 같은 이름으로 채널을 만듭니다. 구독 알림 유형을 전화로 설정하세요. 이 설정이 핵심입니다. 전화 유형 알림은 수신 전화 화면으로 도착해 iOS 집중 모드와 방해 금지 모드를 뚫고 울립니다. 푸시 알림은 그렇게 하지 못합니다.

템플릿은 Alertmanager 페이로드를 직접 읽도록 설정합니다.

Title: 🔴 {{commonLabels.alertname}} on {{commonLabels.instance}}
Body: {{commonAnnotations.summary}}
{{commonAnnotations.description}}

그리고 고급 설정에서 링크 템플릿을 지정하면 알림 기록에서 곧바로 그래프로 이동할 수 있습니다.

{{alerts[0].generatorURL}}

그다음 채널의 Webhook URL을 복사합니다.

https://hook.echobell.one/t/<channel-token>

이 URL은 비밀 정보로 다루세요. 이걸 가진 사람은 누구든 당신의 전화를 울릴 수 있습니다.

2단계 — webhook 리시버 추가하기

alertmanager.yml에서:

route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-critical

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false

curl -X POST http://localhost:9093/-/reload 또는 SIGHUP으로 다시 로드합니다.

send_resolved: false에 주목하세요. **webhook 리시버의 기본값은 true**로, Alertmanager의 다른 대부분 리시버와 반대입니다. 이 줄을 빼면 서비스가 망가졌을 때 전화가 울리고, 스스로 복구됐을 때 또 한 번 울립니다. 바로 그 두 번째 전화가 사람들에게 첫 번째 전화를 무시하도록 가르칩니다. 4단계에서 벨소리 없이 복구 알림을 되찾는 방법을 다룹니다.

3단계 — 실제로 무엇이 도착하는지 이해하기

Alertmanager는 알림을 그룹으로 묶은 뒤, 그룹마다 하나씩 POST합니다.

{
  "version": "4",
  "groupKey": "{}:{alertname=\"HighErrorRate\"}",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "echobell-critical",
  "groupLabels": { "alertname": "HighErrorRate" },
  "commonLabels": { "alertname": "HighErrorRate", "severity": "critical" },
  "commonAnnotations": { "summary": "Error rate above 5% for 10m" },
  "externalURL": "http://alertmanager.internal:9093",
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "HighErrorRate", "instance": "api-7d9f:8080" },
      "annotations": { "summary": "Error rate above 5% for 10m" },
      "startsAt": "2026-09-04T02:41:07.351Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "http://prometheus:9090/graph?g0.expr=...",
      "fingerprint": "a1b2c3d4e5f60718"
    }
  ]
}

Echobell은 JSON 본문을 그대로 읽으므로 위의 모든 필드를 템플릿과 조건에서 쓸 수 있습니다. 중첩 접근은 두 문법 모두 동작합니다 — {{commonLabels.severity}} 또는 {{alerts[0].labels["instance"]}}.

이 페이로드의 두 가지 성질이 이후 모든 것을 좌우합니다.

최상위 status는 그룹 내 알림 중 하나라도 발생 중이면 firing입니다. 그룹의 모든 알림이 해결되어야 비로소 resolved가 됩니다. 그래서 필터 기준으로 삼기에 깔끔합니다.

commonLabels에는 그룹 내 모든 알림이 공유하는 레이블만 담깁니다. 이것이 가장 흔한 함정입니다. group_by가 넓어서 한 번의 웹훅이 서로 다른 인스턴스 세 곳의 HighErrorRate를 담고 있다면 commonLabels.instance는 존재하지 않고, {{commonLabels.instance}}는 빈 문자열로 렌더링됩니다. 아래에 이를 다루는 별도 절이 있습니다.

4단계 — 복구는 조용한 푸시로 보내기

무언가 복구됐다는 사실은 여전히 알고 싶습니다. 다만 그것 때문에 전화를 받고 싶지 않을 뿐입니다. Prometheus Recovered라는 두 번째 Echobell 채널을 만들고 알림 유형을 일반으로 설정한 뒤 이 템플릿을 넣습니다.

Title: ✅ {{commonLabels.alertname}} resolved
Body: {{commonAnnotations.summary}}

그리고 고급 설정에 이 조건을 넣습니다.

status == "resolved"

조건은 무엇이든 전달되기 전에 평가되는 표현식입니다. 표현식이 거짓이면 Echobell은 요청을 수락하되 아무것도 보내지 않습니다.

그다음 같은 리시버가 두 채널을 모두 가리키게 합니다. 하나의 리시버는 여러 개의 webhook_configs를 가질 수 있습니다.

receivers:
  - name: echobell-critical
    webhook_configs:
      # 전화를 울린다. 발생 시에만.
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false
      # 조용한 푸시. 채널 조건이 firing 쪽을 걸러낸다.
      - url: "https://hook.echobell.one/t/<recovery-channel-token>"
        send_resolved: true

복구 채널은 firing과 resolved 페이로드를 모두 받고 firing 쪽을 버립니다. 결과적으로 장애에는 전화가 울리고, 복구는 아침에 읽을 푸시로 도착합니다.

5단계 — 전부가 아니라 심각도별로 라우팅하기

모든 알림을 전화 채널로 보내는 catch-all 라우트는 무시당하는 전화를 대량 생산하는 기계입니다. 라우팅 트리가 있어야 할 자리인 Alertmanager에서 심각도로 나누세요.

route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-warning

  routes:
    # Watchdog은 절대 사람에게 도달하지 않는다. 6단계 참고.
    - matchers:
        - alertname = "Watchdog"
      receiver: "null"

    - matchers:
        - severity = "critical"
      receiver: echobell-critical
      group_wait: 10s
      repeat_interval: 1h

receivers:
  - name: "null"

  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false

  - name: echobell-warning
    webhook_configs:
      - url: "https://hook.echobell.one/t/<normal-channel-token>"
        send_resolved: true

라우트는 위에서 아래로 평가되며 처음 일치한 것이 이깁니다 — continue의 기본값은 false입니다. 따라서 순서가 중요합니다. Watchdog 라우트는 그것을 삼켜버릴 수 있는 규칙보다 위에 있어야 합니다.

채널 하나만 두고 Echobell 쪽에서 필터링하고 싶다면, 동등한 조건은 이렇습니다.

status == "firing" && commonLabels.severity == "critical"

보통은 Alertmanager 쪽이 낫습니다. 거기서는 severity가 group_wait와 repeat_interval까지 함께 제어하기 때문입니다. Echobell 쪽이 나은 경우는 오늘 안에 설정 변경을 머지할 수 없을 때입니다.

6단계 — Watchdog 함정

kube-prometheus-stack을 쓴다면 표현식이 vector(1)인 Watchdog 알림이 있습니다. 이 알림은 항상 발생하도록 설계되어 있습니다. Prometheus 자체가 멈췄다는 사실을 외부 시스템이 알아차릴 수 있게 하려고 존재하기 때문입니다. 기본 설정은 이것을 null 리시버로 라우팅합니다.

이것을 제외하지 않은 채 catch-all 라우트를 전화 채널로 향하게 하면, Watchdog은 repeat_interval마다, 영원히, 그것도 즉시부터 당신에게 전화를 겁니다. 사람들이 "전화 알림은 못 쓰겠다"고 결론짓는 1순위 원인이 바로 이것입니다.

5단계의 null 라우트를 그대로 두세요. 그리고 선택적으로, 그것으로 유용한 일을 하십시오. Watchdog을 진짜 데드맨 스위치로 바꾸는 것입니다.

    - matchers:
        - alertname = "Watchdog"
      receiver: deadmansswitch
      group_wait: 0s
      group_interval: 1m
      repeat_interval: 50s

receivers:
  - name: deadmansswitch
    webhook_configs:
      - url: "https://hc-ping.com/<your-check-uuid>"
        send_resolved: false

Echobell 자체는 데드맨 스위치가 될 수 없습니다. 요청이 도착할 때 알리는 것이지, 요청이 끊겼을 때 알리는 것이 아니기 때문입니다. 그러니 Watchdog 핑은 침묵 감지를 위해 만들어진 서비스(Healthchecks.io, Cronitor, Dead Man's Snitch)로 보내고, 그 서비스의 "체크 다운" 웹훅을 Echobell 전화 채널로 향하게 하세요. 이제 전화가 울린다는 것은 "모니터링 자체가 죽었다"는 뜻이 됩니다. 가장 깨어나고 싶은 알림이자, 아무도 설정하지 않는 알림입니다.

양치기 소년이 되지 않도록 조정하기

Alertmanager의 세 가지 설정이 대부분의 일을 하고, Prometheus에 하나가 더 있습니다.

설정위치역할
for:알림 규칙실제로 발생하기까지 조건이 유지되어야 하는 시간. 2초짜리 순간 장애에 대한 1차 방어선.
group_wait라우트첫 알림 전에 다른 알림을 기다리는 시간. 기본 30s이며 critical은 10s로 낮춥니다.
group_interval라우트기존 그룹의 새 알림에 대해 통지하기까지의 최소 간격. 기본 5m.
repeat_interval라우트해결되지 않은 알림을 다시 통지하는 주기. 기본 4h — 즉 야간 장애는 03:00에 전화하고 07:00에 또 겁니다.

고민할 가치가 있는 건 repeat_interval입니다. 네 시간은 무언가를 망가진 채 두기엔 길고, 20분은 결국 채널을 꺼버리게 만드는 장치입니다. critical에 한 시간 정도가 합리적인 출발점입니다.

받지 못한 전화를 다음 repeat_interval까지 기다리지 않고 즉시 재시도하게 하려면, Echobell 앱 설정에서 실패한 통화 재시도를 켜세요.

업무 시간 외에만 울리게 하기

업무 시간에는 이미 대시보드를 보고 있을 가능성이 큽니다. Echobell의 시스템 시간 변수(모두 UTC)를 쓰면 Alertmanager에 두 번째 라우트를 만들지 않고도 채널이 시간대별로 다르게 동작하게 할 수 있습니다.

status == "firing" && (hour >= 17 || hour < 9)

이렇게 하면 UTC 09:00–17:00 밖에서만 전화가 옵니다. 낮 시간 푸시용으로는 일반 유형의 두 번째 채널을 반대 구간에 맞춥니다.

status == "firing" && hour >= 9 && hour < 17

dayOfWeek >= 1 && dayOfWeek <= 5를 추가하면 주말도 업무 시간 외로 취급됩니다. 이 값들은 항상 UTC로 계산되므로 자신의 시간대만큼 보정하세요. 더 자세한 내용은 Echobell에서 UTC 조건으로 시간 구간 알림 만들기를 참고하세요.

commonLabels가 비는 문제 다루기

그룹에 여러 인스턴스의 알림이 섞이면 commonLabels.instance가 사라지고 알림 제목이 🔴 HighErrorRate on 가 되어 버립니다.

권장 순서대로 세 가지 해법이 있습니다.

  1. 해당 레이블을 group_by에 넣기. group_by에 instance가 포함되면 그룹 내 모든 알림이 이를 공유하므로 commonLabels.instance가 항상 존재합니다. 대가는 알림 수 증가입니다. 알림 이름당 하나가 아니라 인스턴스당 하나가 됩니다.
  2. 첫 번째 알림을 대신 읽기. {{alerts[0].labels.instance}}는 언제나 값이 있습니다. 다만 여럿 중 하나일 뿐이니 개수와 함께 쓰세요: {{alerts[0].labels.instance}} (총 {{alerts.length}}건).
  3. 비어 있어도 읽히도록 레이블을 설계하기. Echobell에는 기본값 연산자가 없습니다 — {{a || "unknown"}}은 대체값이 아니라 리터럴 true를 렌더링합니다 — 그러니 Instance: {{commonLabels.instance}}를 한 줄로 따로 두어, 빈 값이 문장을 깨뜨리는 대신 명백히 비어 보이게 하세요.

페이로드를 작게 유지하기

파드 100개를 아우르는 그룹은 큰 JSON 본문을 만들고, Echobell은 1 MiB를 넘는 트리거 본문을 HTTP 413으로 거부합니다. Alertmanager에서 상한을 두세요.

      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false
        max_alerts: 20

그러면 Alertmanager는 최대 20건만 보내고, 버린 개수를 truncatedAlerts에 담습니다. 본문에 표시할 수도 있습니다.

Body: {{commonAnnotations.summary}}
Alerts: {{alerts.length}} (+{{truncatedAlerts}}건 잘림)

팀과 알림 공유하기

Echobell 채널은 구독 링크로 공유할 수 있고, 구독자마다 자신의 알림 유형을 고릅니다. 따라서 같은 라우트로 온콜 엔지니어의 전화는 울리게 하면서 나머지 사람들에게는 일반 푸시로 도착하게 할 수 있습니다. 좌석당 과금도, Alertmanager의 추가 라우팅 규칙도 필요 없습니다.

이는 애초에 많은 팀이 Prometheus를 자체 호스팅하는 이유와도 잘 맞습니다. 메트릭과 알림 규칙은 여러분의 인프라에 남고, Echobell은 알림 내용과 기록을 서버가 아니라 기기에 보관합니다.

이 구성이 제공하지 않는 것

경계를 솔직히 밝혀 두면 나중에 잘못된 마이그레이션을 피할 수 있습니다. Echobell은 전달 계층이지 인시던트 관리 플랫폼이 아닙니다. 다음은 없습니다.

  • 온콜 교대 일정이나 follow-the-sun 인수인계
  • 첫 담당자가 받지 않으면 두 번째 사람을 호출하는 에스컬레이션 트리
  • 인시던트 타임라인, 확인(ack) 추적, 포스트모템 도구

팀에 이런 것들이 필요하다면 PagerDuty나 Grafana Cloud IRM 같은 제품이 필요합니다. 여기서 다룬 것은 Alertmanager가 열어 둔 구체적인 빈틈, 즉 발생한 알림을 실제로 울리는 전화로 바꾸는 일뿐입니다. 1인 운영자, 소규모 팀, 홈랩에는 대개 그것이 요구사항의 전부입니다.

문제 해결

아무것도 도착하지 않습니다. 먼저 Alertmanager 자체 로그(level=error component=dispatcher)를 확인한 뒤, 라우트가 실제로 해당 리시버로 해석되는지 확인하세요. amtool config routes test severity=critical alertname=HighErrorRate를 쓰면 실제 알림이 발생하기를 기다리지 않고도 어느 리시버로 떨어질지 알 수 있습니다.

Echobell이 HTTP 404를 반환합니다. 채널 토큰이 틀렸거나 채널이 삭제되었습니다. 알 수 없는 토큰은 404이며, 조용한 성공이 아닙니다.

Echobell이 200과 "notificationTriggered": false를 반환합니다. 조건이 거짓으로 평가되었습니다. 응답 본문에는 "conditionsMet": false도 함께 담기며, "조건이 잘못됐다"와 "웹훅이 아예 안 왔다"를 가장 빠르게 구분하는 방법입니다. Alertmanager가 실제로 보낸 값과 대조해 status == "firing"을 확인하세요. alerts[0].status가 아니라 최상위 status입니다.

HTTP 413. 페이로드가 1 MiB를 넘었습니다. 위처럼 max_alerts를 설정하세요.

HTTP 405. 채널에 POST Only가 켜져 있는데 무언가가 GET을 보냈습니다. Alertmanager는 POST를 쓰므로, 보통 브라우저에서 URL을 테스트했다는 뜻입니다.

제목 중간이 비어 있습니다. 해당 그룹의 commonLabels에 그 레이블이 없었습니다. 위 절을 참고하세요.

울리지는 않는데 알림은 옵니다. 구독의 알림 유형이 전화가 아니라 일반 또는 시간 민감으로 되어 있습니다. 알림 유형은 구독자별로 선택하므로, 울리지 않는 기기에서 확인하세요.

프로덕션을 건드리지 않고 테스트하기. expr: vector(1), 고유한 alertname, severity: critical을 가진 규칙을 추가해 한 번 발생시킨 뒤 삭제하세요. 또는 직접 하나 보내도 됩니다.

curl -X POST http://localhost:9093/api/v2/alerts -H 'Content-Type: application/json' -d '[
  {"labels":{"alertname":"EchobellTest","severity":"critical"},
   "annotations":{"summary":"Testing the phone call path"}}
]'

자주 묻는 질문

Prometheus Alertmanager가 자체적으로 전화를 걸 수 있나요?

걸 수 없습니다. Alertmanager에는 이메일, Slack, PagerDuty, OpsGenie 등 많은 리시버가 있지만 음성 리시버도 SMS 리시버도 없습니다. 전화를 걸려면 범용 webhook 리시버를 Echobell처럼 통화가 가능한 서비스로 라우팅하거나, 인시던트 관리 플랫폼에 비용을 지불해야 합니다.

전화 알림이 방해 금지 모드를 뚫나요?

뚫습니다. Echobell의 전화 알림 유형은 수신 전화로 표시되며, iOS 집중 모드와 방해 금지 모드를 통과해 울립니다. 자세한 내용과 관련 설정은 iOS 집중 모드를 뚫고 중요 알림을 받는 방법을 참고하세요.

방화벽 뒤나 Kubernetes 안의 Alertmanager에서도 되나요?

됩니다. 이 웹훅은 Alertmanager에서 나가는 아웃바운드 HTTPS 요청이므로 hook.echobell.one에 도달할 수만 있으면 됩니다. Alertmanager에 공인 주소나 인그레스는 필요 없습니다.

알림이 해결될 때 전화가 오지 않게 하려면?

전화 채널을 가리키는 webhook 설정에 send_resolved: false를 지정하세요. webhook 리시버는 Alertmanager의 다른 대부분 리시버와 달리 기본값이 true이므로, 옵트인이 아니라 옵트아웃입니다. 그래도 복구 소식을 조용히 받고 싶다면 status == "resolved" 조건을 가진 두 번째 채널을 추가하세요.

왜 같은 알림으로 네 시간마다 전화가 울리나요?

repeat_interval 때문이며 기본값은 4h입니다. Alertmanager는 여전히 발생 중인 알림을 이 주기로 다시 통지합니다. 라우트별로 설정하세요. critical에 1h가 흔한 선택입니다. catch-all 라우트를 추가한 직후부터 전화가 시작됐다면, 범인은 항상 발생하는 Watchdog 알림일 가능성이 높습니다. 6단계를 보세요.

같은 알림으로 여러 사람에게 전화할 수 있나요?

가능합니다. 채널을 동료와 공유하면 구독자마다 알림 유형을 고릅니다. 전화 채널을 구독한 모든 사람에게 전화가 가며, 좌석당 비용도 없습니다.

심각도 필터링은 Alertmanager와 Echobell 조건 중 어디서 해야 하나요?

Alertmanager를 우선하세요. 거기서 라우팅하면 심각도별로 group_wait와 repeat_interval까지 설정할 수 있고, 라우팅 트리가 나머지 설정과 함께 버전 관리에 남습니다. Echobell 조건은 Alertmanager 설정을 바꿀 수 없을 때, 또는 Alertmanager에 개념 자체가 없는 필터(예: 하루 중 시간대)에 쓰세요.

마무리

구성은 리시버 하나, send_resolved: false 한 줄, 그리고 severity: critical이 아닌 모든 것을 전화 채널에서 떼어놓는 라우팅 트리가 전부입니다. 기존 알림 규칙, 그룹화, 무음 처리, 억제 설정은 그대로 두면서, "Prometheus가 알아챘다"와 "사람이 알아챘다" 사이의 틈을 메워줍니다.

iPhone용 Echobell 내려받기 또는 Google Play에서 받기 후, 정말 중요한 일을 이 경로에 맡기기 전에 위의 EchobellTest 알림을 한 번 발생시켜 보세요.

관련 글

관련 글

Uptime Kuma 전화 알림: 장애가 나면 휴대폰이 울리게 만들기

Uptime Kuma는 90가지가 넘는 알림 제공자를 지원하지만 전화를 걸어 주는 것은 없습니다. Webhook 하나로 장애 발생 시 전화 알림을 추가하는 방법을 소개합니다.

더 보기

CRA의 24시간 시계는 2026년 9월 11일에 시작됩니다: 반드시 누군가 받게 하세요

2026년 9월 11일부터 EU 사이버 복원력법은 제조자에게 조기 경보를 제출할 24시간을 줍니다. 제출은 브라우저에서만 가능하고 보고용 API는 없습니다. 이 트리거를 Echobell로 전화까지 연결하는 방법과, 알림을 더 크게 울려도 해결되지 않는 부분을 정리했습니다.

더 보기

야간 거래 알림: 12월 6일, 시장이 문을 닫지 않게 됩니다

2026년 12월 6일부터 미국 주식은 23시간 거래 체제로 바뀌고, CME의 암호화폐 파생상품은 5월부터 24시간 내내 거래되고 있습니다. Echobell로 야간 가격 알림을 울리는 전화로 바꾸는 방법, 그리고 알림을 더 크게 만드는 것만으로는 해결되지 않는 문제를 정리했습니다.

더 보기