상태 판정 로직
CronBark은 수신한 이벤트와 시간 경과를 종합해 각 Cronjob의 상태를 자동 판정합니다.
상태 우선순위 (고정)
failed > timeout > delayed > running > success > never_run같은 Cronjob에서 여러 상태가 동시에 성립할 수 있을 때, 위 순서대로 더 위에 있는 상태가 UI에 표시됩니다.
각 상태의 판정 기준
| 상태 | 판정 조건 |
|---|---|
running | start 이벤트를 받았고 아직 success/fail을 받지 않음 |
success | success 이벤트 수신 |
failed | fail 이벤트 수신 |
delayed | running 상태인데 경과 시간이 지연 임계값을 초과 |
timeout | running 상태인데 경과 시간이 타임아웃 설정값을 초과 |
never_run | 등록 이후 한 번도 실행 이력이 없음 |
지연 vs 타임아웃
두 상태는 비슷해 보이지만 용도가 다릅니다.
- 지연(delayed) — “예상보다 오래 걸리는 중” 경고. Cronjob은 아직 실행 중일 수도 있고, 단순히 성공 보고를 아직 못 받았을 수도 있습니다. 사용자가 설정한 값보다 길어지면 알림이 나가지만 상태는 계속 업데이트 됩니다.
- 타임아웃(timeout) — “이 잡은 사실상 죽었다”고 판단. 타임아웃 이후에는 해당 Execution을 실패로 간주하고, 다음 start 이벤트가 오면 새 Execution으로 처리합니다.
판정 주기
CronBark는 30초마다 실행 중인 모든 작업을 스캔해서 지연/타임아웃 여부를 갱신합니다. 따라서 상태 변경은 최대 30초 이내에 반영됩니다.
알림과의 관계
상태 판정은 알림 조건과 독립적으로 동작합니다. 즉, 상태는 항상 판정되지만 알림은 사용자가 설정한 규칙이 일치할 때만 발송됩니다.
중복 알림 방지: 같은 실행에 대해 동일한 조건의 알림은 한 번만 발송됩니다.
cron 표현식과 상태 판정의 관계
CronBark 는 push 기반 입니다. 등록 시 입력한 cron 표현식 시간이 되면 CronBark 가 알아서 검사를 시작하는 것이 아니라, 여러분의 배치가 ping 을 쏴줘야 상태가 감지됩니다.
따라서 위의 상태 판정에 쓰이는 시간 기준은 모두 분 단위 임계값 이고, cron 표현식 자체는 판정 로직에 들어가지 않습니다.
| 판정 | 기준 |
|---|---|
delayed | start ping 수신 후 지연 임계값(delay_threshold_minutes, 기본 10분) 초과 |
timeout | start ping 수신 후 타임아웃 값(timeout_minutes, 기본 60분) 초과 |
never_run | 등록 이후 ping 한 번도 안 옴 |
cron 표현식은 다음 보조 역할만 합니다.
- 대시보드/상세 페이지에 스케줄 정보 표시
- “다음 실행 예상 시각” 계산해서 안내
- 알림 메일·리포트에 스케줄 컨텍스트 포함
cron 데몬 자체가 죽어서 ping 이 끊기는 경우는 현재 자동 감지하지 않습니다 — push 기반 모니터링의 본질적 한계로, 마지막으로 받은 상태가 그대로 유지됩니다. cron 스케줄 기반 grace time 자동 감지(다음 예상 ping 시각 + 여유 시간 안에 ping 안 오면 알림)는 향후 로드맵에 포함되어 있습니다. 그 전까지 강한 보장이 필요하면 cron 데몬/호스트 자체를 외부 모니터링(UptimeRobot, 시스템 헬스체크 등)으로 별도 감시하시는 것을 권장합니다.
Execution 레코드 수명 주기, 상태 전이 다이어그램 등 상세 가이드를 준비 중입니다. 먼저 보고 싶은 내용이 있다면 cronbark.contact@gmail.com 으로 알려주세요.