heartbeat가 정상으로 들어오는데도 14:00 과업이 실행되지 않으면, 대부분은 시간 도래 판정 누락이나 task-key 중복 차단 로직 오판이 원인이다.
핵심은 현재 시각 비교 → 시작 알림 → 실행 → 체크박스/로그 반영을 한 사이클로 끊김 없이 수행하는 것이다.
칠판 치트시트
오늘 계획의 14:00 항목이[ ]인지 먼저 확인- 현재 시각이 14:00 이상이면 즉시 실행 대상
task-key=날짜|시간|작업명완료 로그가 없을 때만 실행- 완료 후
[x]+[실행완료]1회 기록
flowchart LR A[heartbeat 수신] --> B[오늘 계획 읽기] B --> C{14:00 항목 [ ] && 현재시각>=14:00?} C -- 아니오 --> D[상태만 보고] C -- 예 --> E{동일 task-key 완료로그 존재?} E -- 예 --> F[재실행 금지 + update-only] E -- 아니오 --> G[시작 알림] G --> H[작업 실행] H --> I[체크박스 [x] + 실행완료 로그] I --> J[완료 알림]
가장 빠른 복구 순서
운영자 기준으로는 아래 순서가 가장 안전하다.
memory/YYYY-MM-DD.md에서## 오늘 계획14:00 항목 상태를 확인한다.## 로그에서task-key=YYYY-MM-DD|14:00|...형태의[실행완료]가 있는지 검색한다.- 완료 로그가 없고 시각이 지났다면, 시작 알림을 먼저 보내고 과업을 즉시 실행한다.
- 완료 후 체크박스를
[x]로 바꾸고, 결과가 보이도록 1줄 로그를 남긴다.
현장 미니 사례
사례 A) 14시를 지났는데도 계속 HEARTBEAT_OK만 나감
- 원인: Step2에서 현재 시각 비교를 생략하고 루틴 종료
- 해결:
현재시각>=계획시각조건을 강제하고 도래 항목은 즉시 집행
사례 B) 같은 14시 과업이 여러 번 완료로 찍힘
- 원인: task-key 중복 검사 없이 매 heartbeat 실행
- 해결: 동일 task-key의
[실행완료]존재 시 재실행 금지, 보강은[업데이트]로만 기록
검색형 FAQ
Q1. 13:59 heartbeat에서는 왜 실행하면 안 되나요?
A. 계획시각 도래 전 선실행은 운영 기준을 깨고 중복 실행 가능성을 키운다. 도래 후 즉시 실행이 원칙이다.
Q2. 완료 로그가 있는데 다시 실행해야 하면요?
A. 같은 task-key로는 완료를 추가하지 않고 [업데이트] 로그로 보강 사유와 변경점만 남긴다.
Q3. 시작 알림을 꼭 먼저 보내야 하나요?
A. 네. 실행 누락/중복을 사람이 추적하기 쉬워지고, 운영 신뢰도가 올라간다.
다음 읽기
- 11-Scheduled-reminder-떴는데-액션-안이어질때
- OpenClaw-32-HEARTBEAT_OK-반복응답-해결
- 34-heartbeat-완료한-작업이-다시-미완료로-보일때
- 09-예약-리마인더-중복발송-해결
- 10-Quota-리셋알림-왔는데-quota-exceeded-해결
- 37-Docker-컨테이너-Exit-Code-137-해결
- 38-Docker-stats-메모리-숫자-다르게-보일때
- index
내부링크 보강 (10개)
- OpenClaw-31-Quota-리셋-안됨-해결
- OpenClaw-33-gateway-무응답-pm2-systemd-충돌해결
- OpenClaw-34-세션툴-블로그-검수자동화
- OpenClaw-30-텔레그램-완전설정-운영가이드
- OpenClaw-29-텔레그램-권한변화-버전비교
- OpenClaw-25-크론-서브에이전트-분산운영
- OpenClaw-24-11가지-핵-실전운영가이드
- OpenClaw-21-Archive-PARAZ-리팩터링-실행
- OpenClaw-20-운영아키텍처-규칙총정리
- index
다음 추천 읽기: OpenClaw-31-Quota-리셋-안됨-해결
※ 이 문서는 생성형 AI를 활용해 작성되었습니다.