Hermes Agent 크론 작업이 실행되지 않을 때: Windows 점검 순서

Windows 환경을 기준으로 작성했습니다.AI가 초안을 도운 부분도 사람이 다시 확인합니다.

이 글이 필요한 사람과 바로 답

Hermes Agent에 예약 작업을 만들었는데 정해진 시간이 지나도 실행되지 않거나 Telegram 같은 전송 대상에 결과가 오지 않는다면, 작업을 지웠다가 다시 만들기 전에 세 가지를 분리해서 봐야 합니다. 작업이 활성 상태인지, 스케줄러를 돌리는 게이트웨이가 실행 중인지, 작업은 끝났지만 전송만 실패했는지입니다.

가장 짧은 점검 순서는 hermes cron list로 작업 상태와 다음 실행 시각을 보고, hermes cron status로 스케줄러 상태를 확인한 다음, hermes cron runs <job_id> --limit 3으로 최근 실행 기록을 읽는 것입니다. 공식 문제 해결 문서도 작업 상태, 일정, 게이트웨이, 시스템 시간, 전송 대상을 나눠 확인하도록 안내합니다.[2]

확인한 날짜·환경·전제

확인 날짜: 2026년 9월 1일
환경: Windows 11의 Hermes Agent 네이티브 설치
검증 범위: 읽기 전용 CLI 명령으로 실제 예약 작업의 상태, 게이트웨이, 최근 실행 이력을 확인
전제: 이 글은 Hermes 내부 cron 작업을 다룹니다. Windows 작업 스케줄러에 별도의 명령을 직접 등록한 경우는 범위가 다릅니다.

Hermes 공식 Windows 가이드는 네이티브 Windows에서 cron scheduler를 지원하며, 게이트웨이 자동 시작은 Windows 로그인 항목을 이용한다고 설명합니다.[3] 일반 CLI 창만 열어 둔다고 예약 실행이 시작되는 것은 아닙니다. 공식 cron 문서에 따르면 예약 작업은 게이트웨이의 스케줄러가 주기적으로 확인해 실행합니다.[1]

공식 정보에서 먼저 구분할 것

확인 대상	판단 기준	다음 조치
작업 정의	`active`인지, `paused` 또는 `completed`인지	일시정지는 재개하고, 1회 작업이 끝난 경우 반복 일정으로 새로 만들지 검토
다음 실행 시각	현재 현지 시각보다 미래인지	cron 표현식과 Windows 시간대를 비교
게이트웨이	`hermes cron status`가 자동 실행 가능 상태를 반환하는지	중지 상태라면 게이트웨이 설치·시작 상태 확인
실행 이력	최근 실행이 completed, failed, running 중 무엇인지	실패 원인과 마지막 오류를 확인
전송	작업은 완료됐지만 메시지만 없는지	전송 대상 설정과 `[SILENT]` 응답 여부 확인

Hermes cron은 1회 실행과 반복 실행을 모두 지원합니다. 30m 같은 지연 형식은 30분 뒤 한 번 실행하는 일정이고, every 2h와 5필드 cron 표현식은 반복 일정입니다.[1][2] 한 번 실행된 뒤 completed로 보인다면 고장이라고 단정하기 전에 일정 형식을 확인해야 합니다.

직접 검증 과정과 실제 결과

실제 Windows 11 환경에서 아래 읽기 전용 명령을 차례로 실행했습니다. 작업 ID, 전송 대상, 로컬 경로, 프로세스 번호는 공개 글에 필요하지 않아 기록에서 제외했습니다.

hermes cron --help
hermes cron list
hermes cron status
hermes gateway status
hermes cron runs <job_id> --limit 3
date '+%Y-%m-%d %H:%M:%S %z %Z'

hermes cron --help에서는 list, create, edit, pause, resume, run, remove, status, runs, incidents, tick 등의 하위 명령을 확인했습니다. hermes cron list에서는 점검 대상 작업이 active 상태였고, 5필드 일정과 다음 실행 시각, 직전 실행 결과가 함께 표시됐습니다.

hermes cron status는 게이트웨이가 실행 중이며 cron 작업이 자동으로 실행될 수 있다고 반환했습니다. 활성 작업 수와 다음 실행 시각도 함께 확인됐습니다. hermes gateway status에서는 Windows 로그인 항목과 게이트웨이 프로세스가 모두 실행 중이었습니다. 마지막으로 최근 실행 기록을 조회했을 때 현재 실행은 running, 직전 실행은 completed로 구분됐습니다.

이 결과로 최소한 네 가지를 한 번에 확인할 수 있었습니다. 작업 정의가 남아 있고, 일시정지되지 않았고, 스케줄러가 살아 있으며, 실행 기록도 저장되고 있었습니다. 이런 상태에서 결과 메시지만 보이지 않는다면 작업 생성보다 전송 단계와 [SILENT] 조건을 먼저 살피는 편이 맞습니다.

흔한 실패와 잘못된 접근

일반 채팅 창이 열려 있으니 예약 작업도 돌 것이라고 생각한다

공식 문제 해결 문서는 자동 실행에 게이트웨이가 필요하다고 안내합니다. 일반 CLI 채팅 세션은 예약 작업을 자동으로 발화시키지 않습니다.[2] 채팅이 잘 된다는 사실과 cron 스케줄러가 동작한다는 사실은 별개입니다.

`30m`를 30분마다 실행하는 일정으로 해석한다

30m는 30분 뒤 한 번 실행하는 형식입니다. 30분 간격 반복은 every 30m처럼 적어야 합니다.[2] 한 번 실행된 뒤 completed가 된 작업을 무작정 재개해도 기대한 반복 일정이 되지 않을 수 있습니다.

메시지가 없으니 작업 자체가 실패했다고 결론낸다

실행과 전송은 따로 확인해야 합니다. 최근 실행이 completed인데 메시지만 없다면 전송 대상, 플랫폼 설정, 응답 내용부터 봅니다. 감시 작업이 [SILENT]를 반환하면 전송을 억제하는 동작도 공식 문서에 명시돼 있습니다.[1][2]

문제 해결을 위해 작업부터 삭제한다

삭제하면 기존 일정과 비교할 근거가 사라집니다. 먼저 list, status, runs 결과를 확인하고, 필요하면 pause나 edit을 사용합니다. 직접 수정이 필요해도 작업 저장 파일을 손으로 고치는 것보다 Hermes CLI나 관리 도구를 사용하는 편이 안전합니다.[1]

단계별 해결법

현재 시각을 확인합니다. Windows 시계와 명령이 보여 주는 시각·오프셋을 비교합니다. 다음 실행 시각이 예상과 다르면 작업보다 시간대부터 바로잡습니다.
작업이 실제로 남아 있는지 봅니다. hermes cron list에서 이름, 상태, 일정, 다음 실행 시각을 확인합니다. 공유용 캡처를 만들 때는 작업 ID와 전송 대상을 가립니다.
게이트웨이와 cron 상태를 확인합니다. hermes cron status와 hermes gateway status를 실행합니다. 게이트웨이가 중지됐다면 hermes gateway start를 사용한 뒤 상태를 다시 읽습니다. 이 명령은 상태를 바꾸므로, 회사 PC에서는 운영 정책을 먼저 확인합니다.
최근 실행 기록을 확인합니다. hermes cron runs <job_id> --limit 3으로 최근 상태를 봅니다. 실행 기록이 없다면 일정과 게이트웨이 쪽 문제일 가능성이 큽니다. completed가 있다면 전송 단계까지 범위를 좁힐 수 있습니다.
테스트 실행은 기존 작업을 복제하기 전에 합니다. hermes cron run <job_id>은 다음 스케줄러 틱에서 실행되도록 요청하는 테스트 방법입니다.[1] 즉시 화면에 결과가 뜨지 않는다고 연속으로 여러 번 요청하지 마세요.
결과가 없으면 전송 조건을 봅니다. 전송 대상의 대소문자, 플랫폼 연결, 봇 권한, 작업 프롬프트의 [SILENT] 조건을 확인합니다. 작업이 completed라면 스케줄보다 이 단계가 우선입니다.

복사해서 쓰는 진단 기록 템플릿

아래 템플릿은 오류를 재현하거나 지원을 요청할 때 쓸 수 있습니다. 명령 출력 전체를 붙이지 말고 필요한 상태만 옮겨 적습니다.

[Hermes cron 진단]
확인 시각과 시간대:
Windows 버전:
작업 상태: active / paused / completed / 없음
일정 형식: 반복 / 1회
다음 실행 시각:
cron status: 자동 실행 가능 / 중지 / 오류
gateway status: 실행 / 중지 / 미설치
최근 실행 3건: running / completed / failed / 기록 없음
결과 전송: 도착 / 미도착 / [SILENT] 예상
마지막 오류 요약:
이미 시도한 조치:

검증 체크리스트

작업이 active 상태인가?
일정이 1회 형식인지 반복 형식인지 구분했는가?
다음 실행 시각과 Windows 현지 시각의 시간대가 같은가?
hermes cron status가 자동 실행 가능 상태를 보여 주는가?
hermes gateway status에서 게이트웨이가 실행 중인가?
최근 실행 이력에 completed 또는 failed 기록이 있는가?
작업은 완료됐지만 전송만 실패한 상황은 아닌가?
프롬프트가 정상 상황에서 [SILENT]를 반환하도록 되어 있지 않은가?

보안과 개인정보 주의사항

hermes cron list 출력에는 작업 프롬프트, 실행 폴더, 전송 대상 식별자가 나타날 수 있습니다. 화면 캡처나 문의 글에 원문을 그대로 올리지 마세요. 작업 ID도 운영 정보이므로 외부 공유본에서는 일부를 가리는 편이 좋습니다.

플랫폼 토큰이나 비밀번호를 확인하려고 자격증명 파일 내용을 출력하지 마세요. 이 글의 점검 순서는 상태 명령과 실행 이력만으로 범위를 좁히도록 구성했습니다. 로그를 공유해야 한다면 토큰, 사용자 폴더, 이메일, 채팅 식별자, 고객 문서명이 없는지 먼저 검색합니다.

한계와 직접 확인하지 못한 부분

이번 직접 검증은 Windows 11에서 이미 설치된 게이트웨이와 활성 작업을 대상으로 했습니다. 일부러 게이트웨이를 중지하거나 잘못된 전송 대상을 만들어 장애를 재현하지는 않았습니다. Telegram 등 외부 플랫폼의 권한 오류와 회사 보안 정책이 Windows 로그인 항목을 차단하는 경우도 이번 테스트 범위 밖입니다.

Hermes는 업데이트가 잦으므로 하위 명령과 표시 항목은 달라질 수 있습니다. 이 글의 명령이 현재 설치본에서 보이지 않으면 hermes cron --help를 먼저 실행하고, 아래 공식 문서의 최신 내용을 확인하세요.

결론: 실행 문제와 전송 문제를 먼저 나눈다

Windows에서 Hermes Agent cron이 멈춘 것처럼 보일 때는 새 작업을 만드는 것보다 상태를 분리해서 보는 편이 빠릅니다. list로 작업과 시간을 확인하고, status로 스케줄러를 확인하고, runs로 실제 실행 여부를 확인합니다. completed 기록이 있는데 메시지만 없다면 일정 문제가 아니라 전송 문제일 가능성이 큽니다.