---
title: "Cron 작업 실패 알림: 예약 작업이 멈추면 전화로 알려 드립니다"
description: "Cron 작업은 조용히 실패합니다. 실패하거나 누락된 예약 작업을 감지하고 몇 초 안에 푸시 알림이나 전화를 받는 세 가지 확실한 패턴을 알아보세요."
date: 2026-07-16
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - cron 작업
  - 실패 알림
  - 전화 알림
  - 모니터링
  - Webhook
---

# Cron 작업 실패 알림: 예약 작업이 멈추면 전화로 알려 드립니다

실패한 cron 작업이 위험한 이유는 아무 일도 일어나지 않는다는 점입니다. 오류 페이지도, 크래시도, 항의하는 사용자도 없습니다 — 3주 전에 조용히 멈춰 버린 백업, 끝내 발송되지 않은 리포트, 디스크가 가득 차 프로덕션이 무너질 때까지 방치된 정리 스크립트만 남을 뿐입니다.

cron 자체에는 알림 기능이 전혀 없습니다. 작업이 오류로 종료되어도 cron은 아무런 반응을 하지 않습니다. 예정된 시각에 서버가 다운되어 있으면 작업은 아예 실행되지 않고, 실행되지 않았다는 사실을 알려 줄 흔적조차 남지 않습니다. 대부분의 모니터링 구성이 놓치는 것이 바로 이 두 번째 경우입니다.

이 가이드에서는 두 가지 유형의 실패를 모두 잡아내는 세 가지 패턴과, [Echobell](/ko)로 알림을 실제 전화 통화까지 끌어올려 절대 놓칠 수 없게 만드는 방법을 다룹니다.

## 패턴 1: 종료 코드 훅으로 실패 알리기

가장 간단한 방법은 작업이 0이 아닌 상태로 종료될 때마다 Webhook을 호출하는 것입니다.

먼저 Echobell에서 채널을 만들고 Webhook URL을 복사합니다. 그런 다음 cron 명령을 다음과 같이 감쌉니다:

```bash
0 3 * * * /opt/scripts/backup.sh || curl -s "https://hook.echobell.one/t/<channel-token>?title=Backup+failed&host=$(hostname)"
```

`backup.sh`가 성공하면 아무 일도 일어나지 않습니다. 실패하면 Echobell이 몇 초 안에 휴대폰으로 알림을 전달합니다. 쿼리 파라미터는 [템플릿 변수](/ko/docs/template)가 되므로, 어떤 호스트의 어떤 작업이 실패했는지 알림에 정확히 담을 수 있습니다.

스크립트가 길다면 trap을 사용해 더 풍부한 정보를 함께 보낼 수 있습니다:

```bash
#!/usr/bin/env bash
set -euo pipefail

notify_failure() {
  curl -s -X POST "https://hook.echobell.one/t/<channel-token>" \
    -H "Content-Type: application/json" \
    -d "{\"job\":\"nightly-backup\",\"host\":\"$(hostname)\",\"line\":\"$1\"}"
}
trap 'notify_failure $LINENO' ERR

# ... 작업 로직 ...
```

한 가지 한계가 있습니다. 이 방식은 스크립트가 실제로 실행되어 실패할 때만 동작합니다. 서버가 다운되었거나 cron 설정이 잘못되었거나 디버깅 중에 누군가 해당 줄을 주석 처리했다면 알림은 전혀 발생하지 않습니다. 그래서 패턴 2도 함께 필요합니다.

## 패턴 2: 누락된 실행을 잡는 데드맨 스위치

데드맨 스위치는 논리를 뒤집습니다. 작업이 **성공**할 때 모니터에 핑을 보내고, 모니터는 그 핑이 예정대로 도착하지 **않을 때** 알려 줍니다. 이렇게 하면 오류, 멈춤, 다운된 서버, 삭제된 crontab 항목까지 모든 실패 유형을 잡아낼 수 있습니다.

널리 쓰이는 셀프 호스팅 도구 두 가지가 Echobell과 잘 어울립니다:

- **[Healthchecks.io](https://healthchecks.io)**는 바로 이 용도로 만들어진 서비스입니다. cron 일정과 유예 시간을 지정해 체크를 만든 뒤, cron 줄 끝에 `&& curl -s https://hc-ping.com/YOUR_UUID`를 붙이면 됩니다. 핑이 늦어지면 Healthchecks가 Webhook을 보내는데, 이를 Echobell 채널로 연결하면 놓친 백업이 울리는 전화로 바뀝니다.
- **[Uptime Kuma](/ko/docs/developer/uptime-kuma)**에는 같은 방식으로 동작하는 "Push" 모니터 유형이 있습니다. 작업이 푸시 URL을 호출하고, 하트비트가 더 이상 도착하지 않으면 Uptime Kuma가 알림 연동을 통해 알려 줍니다.

두 경우 모두 흐름은 같습니다. cron 작업 → 성공 핑 → 모니터가 침묵을 감지 → Echobell로 Webhook 전송 → 푸시 알림 또는 전화입니다.

## 패턴 3: 데이터를 남기는 작업을 위한 시간대 검사

어떤 작업은 종료 코드보다 결과물로 검증하는 편이 낫습니다. 야간 ETL이 새벽 4시까지 행을 삽입해야 한다면, 작은 검증 작업이 행 수를 확인하고 수치가 이상할 때 Echobell Webhook을 호출하도록 만들 수 있습니다.

이때는 Echobell의 [조건](/ko/docs/conditions) 기능이 도움이 됩니다. 실행할 때마다 상태 Webhook을 보내고, 알릴지 여부는 채널이 판단하도록 맡기면 됩니다. `status != "ok"` 같은 조건을 쓰면 성공한 실행은 조용히 넘어가고, 내장 UTC 시간 변수를 이용하면 작업이 끝나 있어야 할 시간대로만 알림을 제한할 수 있습니다.

## 알림을 절대 놓칠 수 없게 만들기

감지는 문제의 절반일 뿐입니다. 새벽 3시에 소리 없는 배너로 도착하는 백업 실패 알림은 사실상 알림이 없는 것과 같습니다.

Echobell에서는 채널마다 긴급도를 선택할 수 있습니다:

- **일반** — 평범한 푸시 알림으로, 정보성 작업에 적합합니다
- **긴급** — iOS 집중 모드를 뚫고 전달되며, 누군가 곧 확인해야 하는 작업에 알맞습니다
- **전화** — 알아차릴 때까지 실제 전화처럼 휴대폰이 울립니다

조용한 실패가 실제 비용으로 이어지는 작업, 즉 데이터베이스 백업이나 청구 처리, 인증서 갱신 같은 작업에는 채널을 **전화**로 설정하세요. "새벽 3시에 확인했다"와 "오전 9시에 확인했다"의 차이가 바로 [전화 알림](/ko/features/call-notifications)이 만들어 내는 차이입니다.

한 작업을 여러 사람이 함께 책임진다면 채널의 구독 링크를 팀에 공유하세요. 구독한 모든 사람이 같은 순간에 같은 알림을 받습니다.

## 어떤 패턴을 선택해야 할까요?

- **종료 코드 훅**: 5분이면 설정할 수 있고, 명시적인 실패를 잡아냅니다. 여기서 시작하세요.
- **데드맨 스위치**: 누락된 실행과 멈춰 버린 실행까지 잡아냅니다. 실패하면 정말 곤란해지는 작업마다 추가하세요.
- **시간대 데이터 검사**: "실행은 성공했지만 결과가 엉망"인 상황이 실제 위험인 파이프라인에 적합합니다.

세 가지는 서로 잘 맞물립니다. 종료 코드 훅은 작업이 실패했다는 사실과 그 이유를 알려 주고, 데드맨 스위치는 스스로 알릴 기회조차 없었던 실패까지 반드시 전해 줍니다.

첫 cron 알림은 몇 분이면 설정할 수 있습니다. [Echobell 다운로드](/ko) 후 채널을 만들고 crontab에 `curl` 한 줄을 추가하세요. 다음번에 예약 작업이 새벽 3시에 멈추면 휴대폰이 울릴 것이고, 다음 분기에 복원하게 될 백업은 실제로 존재할 것입니다.